4 ms·

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 lockf

by luhn 5y ago

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`.

judge2020 5y ago
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---npm https://github.com/actions/cache/blob/main/examples.md#node-...
- toastal 5y ago
  Aside: would be great if they actually used XDG directories despite many open bugs.
m1keil 5y ago
> 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.
- dathinab 5y ago
  > 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.
- xyzzy_plugh 5y ago
  > 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.
  - Sander_Marechal 5y ago
    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.
  - shantnutiwari 5y ago
    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
raihansaputra 5y ago
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.
- Sander_Marechal 5y ago
  - `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
dathinab 5y ago
> 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).

by luhn 5y ago

judge2020 5y ago

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---npm https://github.com/actions/cache/blob/main/examples.md#node-...

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

m1keil 5y ago

> 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.

dathinab 5y ago
> 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.
xyzzy_plugh 5y ago
> 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.
- Sander_Marechal 5y ago
  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.
- shantnutiwari 5y ago
  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

raihansaputra 5y ago

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.

Sander_Marechal 5y ago
- `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

dathinab 5y ago

> 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).