Hacker News Reader

Comment by luhn | Hacker News Reader

But the npm/JS doesn't work that way.

NPM will by default create a lockfile that pins the dependencies. `npm install` will install dependencies from the lockfile as long as package.json hasn't been updated, or update the lockfile if it has. `npm ci` will install from the lockfile and fail hard if it can't satisfy the version constraints in package.json.

imo this gives the best of both worlds: Easy, controlled updates to the latest compatible versions and stable CI/CD.

The reason color.js was an issue is because people use `npm install` in their CI and either don't commit their lockfiles or have their lockfile inadvertently out of date—It's easy to do and I'm not sure how many people actually know about `npm ci`.

View on HN

> as long as package.json hasn't been updated, or update the lockfile if it has

There is a problem here: it will update the __entire__ package-lock.json file, regardless of the actual changes in packages.json.

Pinning doesn't help here if colors dependency is not your direct dependency.

So you can have a pinned library that doesn't pin colors.js. Now you make a change in packages.json (say adding or removing another unrelated package). You will end up with colors being bumped to latest.

> So you can have a pinned library that doesn't pin colors.js. Now you make a change in packages.json (say adding or removing another unrelated package). You will end up with colors being bumped to latest.

What the actual fuck. Who designed this fucking tire fire? Are you kidding me? What even is the point of package-lock.json??

I can't believe this. I actually can't. Now I have to audit all our dependencies, thanks.

NPM is pretty bad at this. It frustrates me to no end every time I have to use it. It manages to do everything exactly wrong, especially in comparison to the other package manager I use daily: Composer. That one does everything right.

Its the same in Python (at least with standard virtual envs)- you can pin libraries, but dependencies of the libs are not pinned, and you can get different versions based on which lib is installed first.

Im told poetry fixes this, but havent checked it myself

> There is a problem here: it will update the __entire__ package-lock.json file, regardless of the actual changes in packages.json.

I'm so happy I don't need to fight npm anymore.

> npm ci

Yes, that is the problem.

> people use `npm install`

Yes and not just in the CI but also to install CLI tools user wide on a system and similar.

> not sure how many people actually know about `npm ci`

Idk. either but `npm install` had been the default for years, and a lot of documentation is based on it. Not deprecating `npm install` or changing it's behavior is typical for the npm ecosystem, i.e. having subtle sometimes UX related security issues (at least in my experience, I doubt it got much better).

iirc the biggest issue with `npm ci` before was that it cleared node_modules, which used to be the primary way of caching deps in CI builds, but now most suggest caching ~/.npm[0].

0: https://github.com/actions/cache/blob/main/examples.md#node-...

Aside: would be great if they actually used XDG directories despite many open bugs.

Honestly, `npm install` should come with a big honking warning that the lockfiles will change. Or change the behaviour. This would negate this attack on 90% of the cases.

- `npm install` should just install what's in the lockfile

- `npm update` should update the lockfile

- `npm upgrade` should update the versions in package.json

Reply on news.ycombinator.com