How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow).
2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci.
I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci.
Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.
I wish it were so simple. Maybe I’ve just been bit by too many bugs in npm over time, but I repeatedly see npm i change the lockfile when incrementally installing a new package that was correctly locked. Fortunately at least npm ci has always been reliable.
What do you mean ci is super fast? Is it intended to be caching the packages somewhere other than node_modules?
> I repeatedly see npm i change the lockfile when incrementally installing a new package that was correctly locked
There's been some bugs in the implementation but never had anything in the last few years, other than some people accidentally committing unapplied package.json changes, and built a precommit hook and a server-side check for that in many projects.
> What do you mean ci is super fast? Is it intended to be caching the packages somewhere other than node_modules?
Quality of the packages has been discussed to death, say about that anything you like, but npm has been rock-solid for me in the last few years. Definitely not a joke IMHO.
