Live data from Hacker News

A JavaScript Nightmare

blog.ignaciobrasca.com

31–40 of 101 posts

Re: A JavaScript Nightmare

#31
post #7

tldr: A dependency wasn't pinned, the dependency changed, and stuff broke. Author thinks Javascript sucks. I will say this though: it is infuriating that package managers (every single one I've used, not just NPM) don't default to pinning exact dependency versions, and instead let it "automatically" update minor versions.

That’s why for building your JS bundle you’d use „npm ci“ instead of „npm install“ to avoid random upgrades of your packages. It uses your vc’ed „package-lock.json“ file containing your established dependency tree to build your JS bundle.

However, if you need to integrate a new dependency it might require a later version of a package you already installed. NPM is clunky at times but most of the times it works quite well — despite all the micropackaging madness.

Re: A JavaScript Nightmare

#33
post #10
post #7

tldr: A dependency wasn't pinned, the dependency changed, and stuff broke. Author thinks Javascript sucks. I will say this though: it is infuriating that package managers (every single one I've used, not just NPM) don't default to pinning exact dependency versions, and instead let it "automatically" update minor versions.

The package wasn't following semantic versioning. Only major versions should introduce breaking changes.

Unfortunately, this is purely convention and does not give a 100% guarantee of upgrading to latest minor versions not breaking your code.

Re: A JavaScript Nightmare

#35
The dependency update (i.e package.json lock file change) as I understand it was unrelated to their feature, and should have gone in on its own, and it should have broken CI if it was a serious piece of functionality that warranted a late night debugging session.

It sounds to me they rolled in the dependency update with their features, then had a massive surface area to cover when it flaked out.

Re: A JavaScript Nightmare

#36
post #14

Earlier quoted context omitted.

Would Typescript have solved this though? They still would have been using npm etc

> this.subset.encodeStream is not a function Yes?

TypeScript types work only on compile time. If library changes without changing its public TypeScript signatures it won't help at all.

Also, after coming from real compiled languages I find TypeScript ecosystem not to be robust at all. Change in one file sometimes does not result in compile time error in another file where changed type is used. Yes, it's not an issue with TypeScript itself but with its ecosystem, transpilers and compilers, but that's not something I experienced ever with C# or Java.

Re: A JavaScript Nightmare

#37

I didn't quite understand why they had to debug on the spot, thus working like 36 hours uninterrupted or so. A sane working environment would file a priority 0 bug and address it during working hours. I'm not throwing a rock but oftentimes this sort of heroic behavior is self-inflected. Also why is heroic debugging required on something that is not production? The article mentions it was a "quick demo". Then who give…

it‘s called „motivation“

Re: A JavaScript Nightmare

#39
post #27

Why didn't you check the logs as the first thing to understand what's happening -- a standard operational practice? And then to prevent this, you just lock the dependencies via a lockfile -- a well documented solution. This is just another amateur "javascript bad" post.

Agreed, when they popped out this "such and such isn't a function" I lost the thread. You would know about that before you even started if you just read some logs. Unless they don't have logs, in which case a choice of language isn't going to solve their problems.
Post reply on HN