Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A JavaScript Nightmare

blog.ignaciobrasca.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: A JavaScript Nightmare

#61

Post by rezonant »

G3rn0ti wrote: post #31
yen223 wrote: 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 w…

NPM uses your package-lock.json for normal installs as well. "npm ci" behaves nearly identical to npm install except for a few things, detailed here: https://docs.npmjs.com/cli/v8/commands/npm-ci

Note that actually using package-lock.json to resolve dependency versions is not actually a difference between npm install and npm ci

The real benefit is that npm ci will refuse to work if package.json and package-lock.json disagree, which protects against changing package.json without running NPM install during development.

Re: A JavaScript Nightmare

#62

Post by PUSH_AX »

wiseowise wrote: post #57
PUSH_AX wrote: post #47

Earlier quoted context omitted.

Debatable, and I don’t know how that helps the author. I’m getting huge “silver bullet” sentiment from your replies too.

> > obvious problem that was solved decades ago by static typing > getting huge “silver bullet” sentiment from your replies ???

I didn’t write the first quote, but a comparison to an opinionated strongly typed language where types are a first class citizen, and a typing sandbox with nonsense constructs enabled by antipatterns such as unions (‘string|number’ anyone?)… these are not the same things.

Re: A JavaScript Nightmare

#63

Post by rezonant »

yen223 wrote: post #11
pier25 wrote: post #10

Earlier quoted context omitted.

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

The only change that isn't "breaking" is one that only adds functionality. Otherwise, it changes behavour, and has the potential to break your software. In practice, almost all changes should be major version bumps. Anyway that's besides the point. Let me control when version changes happen!

Patch or major is always a judgement call. Making all changes a major jump is a bad idea, because it means that dependent packages are less likely to adopt important functionality or security fixes.

NPM already gives you a way to control when version changes happen, it's called package-lock.json, and it's used for all NPM installs (both in development and when deploying). Just don't listen to the bootcampers on StackOverflow telling you to delete it whenever anything looks weird.

If you delete package-lock.json, assume every dependency version has changed and regress accordingly. The same is true of all reasonable version-locking package managers.

Re: A JavaScript Nightmare

#64

Post by rezonant »

zaSmilingIdiot wrote: post #15
alessioalex wrote: post #3

Shouldn’t you use fixed versions and use something like ‘npm ci’ to install the exact dependency tree? Feels more like an oversight from the developers rather than a JavaScript problem. When you want to upgrade, only then do you run all regression tests and do so.

I agree with this. But dont just use `npm ci`on prod builds since that would typically include all the dev dependencies as well in your production builds, which is not usually desirable. It might be possible to add the `--only=production` flag to npm ci? But otherwise, as pointed out, pinned versions are needed for all dependencies.

"npm ci" omits dev dependencies by default.

However, "npm install" also adheres to your package-lock.json, and does not update things on you.

npm ci is just npm install with a few tweaks that make it better to use for CI and builds, see here: https://docs.npmjs.com/cli/v8/commands/npm-ci

Re: A JavaScript Nightmare

#65

Post by rezonant »

throw156754228 wrote: post #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.

Exactly, and since this is AWS SDK for S3 we're taking about, and I depend on that same SDK in my own projects and they aren't broken (including using some of the more advanced streaming parts of it), I'm guessing there was a major version update applied somewhere in the dependency tree when it shouldn't have been.

Re: A JavaScript Nightmare

#66

Post by jillesvangurp »

rezonant wrote: post #58
jillesvangurp wrote: post #28

Earlier quoted context omitted.

In a statically compiled language, when APIs change, you get compile errors that show up at build time. It's usually pretty obvious. With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed. That combined with poor test coverage means a lot of potential for things to slip through build and QA processes. I use Kotlin, b…

Friends don't let friends write raw JavaScript. Typescript nearly eliminates the problem you bring up, when used correctly.

That's why I use kotlin-js. It's like typescript with the training wheels removed. I always joke that typescript is a bit of a gateway drug for web developers that know javascript to actually get into other languages. Kotlin-js is a bit of a niche thing of course and soon going to be obsoleted by Kotlin's wasm compiler. But kotlin-js actually works very nicely. Just like typescript, it's a transpiler. Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system).

Re: A JavaScript Nightmare

#67

Post by wiseowise »

PUSH_AX wrote: post #62
wiseowise wrote: post #57

Earlier quoted context omitted.

> > obvious problem that was solved decades ago by static typing > getting huge “silver bullet” sentiment from your replies ???

I didn’t write the first quote, but a comparison to an opinionated strongly typed language where types are a first class citizen, and a typing sandbox with nonsense constructs enabled by antipatterns such as unions (‘string|number’ anyone?)… these are not the same things.

What makes unions antipattern in your view and why TS is a “sandbox with nonsense constructs”?

Re: A JavaScript Nightmare

#68

Post by rezonant »

grujicd wrote: post #56
rezonant wrote: post #46

Earlier quoted context omitted.

The types should be shipped with the code which is nearly ubiquitous for NPM packages these days (at least the ones you should actually be using). If they were, you would catch the issue as soon as you built the app, which should be happening in a CI or deploy process (never commit your compiled code). > Change in one file sometimes does not result in compile time error in another file where changed type is used. Sou…

Granted, I'm a novice in TS/JS world after decades in strongly typed environments so it's possible that I'm doing something wrong. I'm not talking about npm, I experienced these issues in my own code. It's mostly related to ts transpilers. They're fast, they're used in build systems which should be latest and greatest (e.g. Vite), but they're not robust, they don't always catch type changes in dependent files. And no…

Sounds like you are talking about frontend development. In that case you are trading off speed for accuracy. Some dev server tooling has this issue.

Most systems built on Vite though do check across files, so likely that's just a bug in the build system you were using. A bug that is likely fixed.

One thing you can be assured of is that when you actually build your app (hopefully using CI), it will find those problems, because you are not relying on hot reloading to do it.

On the backend side it's far less common to use a build server model, and personally not very warranted -- building a frontend app can take a lot of time and the feedback cycle needs to be short for a dev to be effective. On the backend, a small amount of time rebuilding the app before it is rerun is not nearly as costly. If your Typescript codebase is so large that the feedback cycle of rebuilding is too long, well you have to take the tradeoff, but it's a rare problem.

Understand that the only way a "dev server" style backend build process is saving you time is by not checking the types during recompilation. It wouldn't be surprising that it would miss typing changes.

Re: A JavaScript Nightmare

#69

Post by rezonant »

jillesvangurp wrote: post #66
rezonant wrote: post #58

Earlier quoted context omitted.

Friends don't let friends write raw JavaScript. Typescript nearly eliminates the problem you bring up, when used correctly.

That's why I use kotlin-js. It's like typescript with the training wheels removed. I always joke that typescript is a bit of a gateway drug for web developers that know javascript to actually get into other languages. Kotlin-js is a bit of a niche thing of course and soon going to be obsoleted by Kotlin's wasm compiler. But kotlin-js actually works very nicely. Just like typescript, it's a transpiler. Unlike typescri…

Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a lot. It is definitely a language that is focused on correctness and convenience.

That being said, there isn't too much about Kotlin I miss when I write Typescript in strict mode.

> Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system).

Why is the existence of non-strict mode a concern for you if you are using strict mode? After all, whether you are using Typescript or kotlin-js, you are likely to have JS dependencies, and those might not be written with Typescript strict mode. I guess you could just opt not to use any "native" (Javascript) dependencies and just do it all in Kotlin JS, but beyond a certain point that's not very practical.

Re: A JavaScript Nightmare

#70

Post by number6 »

atoav wrote: post #45
peschu wrote: post #37

Earlier quoted context omitted.

it‘s called „motivation“

Jup, and if your employer doesn't stop you or even expects such behavior that is called a bad work culture. Sure, I would also do long programming sessions on my own things every now and then, but those happen because I am in the flow and it feels like more work to come back into it the other day. But those are my own projects. I don't owe this to my employer. If they want that they could offer me double my current s…

How would the employer know?
Post reply on HN