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 3 hours ago | parent [-]

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.

	▲	an hour ago \| parent \| next [-]
		[deleted]
	▲	whilenot-dev 2 hours ago \| parent \| prev \| next [-]
		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".
	▲	user34283 an hour ago \| parent \| prev [-]
		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.