[whilenot-dev]

You forgot case #4: Worked at a startup where the frontend team thought it was a good idea to use lock files during development, but to do a "fresh" install of all dependecies during the deployment step.

And yes, they still thought they were doing the right thing.

[hennell]

To be fair npm makes (made?) it weirdly hard to use lock files so a lot of people did that by mistake. And when you do use lock, it reinstalls every time so a retagged package can just silently update.

[user34283]

I can’t comment on the behavior of ancient npm versions, but with modern npm I would not even know how to skip using a lockfile.

As for the parent comment about not using the lockfile for the production build, that’s just incredibly incompetent.

Maybe they should hire someone who knows what they are doing. Contrary to the popular beliefs of backend engineers online, you also need some competency to do frontend properly.

In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“.

Pnpm will also do that automatically if the CI environment variable is set.

[cxr]

> In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“.

The grugbrain developer says, "I can use git-add to keep a version controlled copy of the library in my app's source tree with no extra steps after git-clone."

(Pop quiz: what problem were the creators of NPM's lockfile format trying to solve?)

[yearolinuxdsktp]

Lock files were begrudgingly introduced after people who aren’t playing around with move fast and break things cried foul about dependencies being updated unexpectedly. The “semantic versioning” dogma and the illusion of safety that it brings was the original motivation. At NPM’s creation time, mature dep management ecosystems did not have floating versions, they were always pinned.

When you are talking about checking your dependencies in the source tree, you are effectively pinning exact versions, and not using floating/tilde versioning syntax.

[user34283]

That breaks if the library uses build scripts, like for setting up native binaries, or native modules linked against the specific Node version.

If you want a vendored deps model you can look at Yarn Plug and Play which does this via .zip files.

However, I would just stick with regular pnpm and installs.

[cxr]

> That breaks if the library uses build scripts

Uh… no.

> setting up native binaries, or native modules linked against the specific Node version

So the majority of projects—those that don't use binary NodeJS modules—don't have a reason for sidestepping the primary VCS and going along with npm's shoddily designed overlay version control approach?

> However, I would just stick with regular pnpm and installs.

You're not answering the question. npm isn't bedrock, and pnpm certainly isn't. If you're going to introduce (mandate) the use of a tool in the workflow, you should be able to justify it by explaining your rationale for introducing it (and making everyone deal with the associated costs). You should at minimum be able to provide a lucid explanation of the tradeoffs. For good measure, you should be able to disprove the "NPM Null Hypothesis"; you should be able to state a straightforward answer to the question, "What problem is this supposed to be solving?"

[dgoldstein0]

This was true in very old npm - generating the lock file was a separate command - npm shrinkwrap. And many people didn't know they should check in the shrinkwraps. But I think the default flipped before 2020 so that it now always creates package-lock.json files (unless an npm-shrinkwrap.json is present and then it uses /updates that)

[whilenot-dev]

FYI a retagged package would result in a different SHA512 integrity sum and fail the installation process. It won't "just silently update".

Anyway, the point of parent and me wasn't that it was considered to be a "mistake", but people thinking they "are doing the right thing".

[throawayonthe]

doesn't `npm ci` prevent that? it fails if something doesn't match the lockfile, and wipes node_modules before running

this is on some ancient node 16 build i was trying to clean up ci for, so not very recent npm

[noirscape]

npm ci does indeed prevent that. The issue isn't really with npm in specific. Rather, it's with build tools like Microsoft's Oryx, which get pushed in GitHub Actions if you're using Azure App Service. That one by default uses `npm install` on older versions (it's been changed nowadays, but Azure's generated action files have a bad habit of generating with older versions of the actions they're using), even though it's specifically meant for CI usage.

In general, use of npm ci is usually sparsely documented - most node projects you can find just recommend using npm install during the setup, suggesting a failure in promoting it's availability (I only know of it because I got frustrated that the lockfile kept clogging up git commits whenever I added dependencies with what looked like auto-generated build-time junk).

[pseudohadamard]

Another example of this is Python and its awful externally-managed-environment handling, for which the procedure for anyone who doesn't use Python every day boils down to:

1. Get instructions from somewhere, a web page, HOWTO, whatever, telling you to "pip install thing".

2. "× This environment is externally managed"

3. Spend awhile Googling how to get past this and just make the damn thing work while swearing.

This is from observing users in practice. Google "This environment is externally managed" and you'll get nothing but hits on (a) people asking what this means and how to make it go away and (b) various unsafe methods to make it so.

[DHRicoF]

How else are you sure your team does not conflict with itself?

/s

[gwerbin]

This is one of those bizarre "how did you even get that idea" mistakes that ironically replacing developers with AI slop farmers might actually improve on. If you ask Claude to set up a project with NPM and CI, it's not going to do weird shit like that.

[yearolinuxdsktp]

I asked Claude to set up a new NPM project and it configured the install task as “npm ci || npm install”, which is stupid. That was on Opus4.7 xhigh. When I pointed out that doing so defeats the purpose, it said “oh yeah of course.”

Turns out there is no equivalent to “npm ci” that doesn’t clear node_modules first, and you can’t call npm install to simulate NPM ci behavior (sans clean).