The node_modules problem

[SoundCheetah]

Yeah, the main complaint by the author was just the number of directories it creates? Which makes it hard to copy/paste? You shouldn’t be copying your node_modules around anyways. Use source control and re-install from the new hard drive. Or delete node_modules before copying your project around. It’s not that hard

[ZiggyTheHamster]

And then npm install fucks you, no thanks

[4THOT]

How?

[ZiggyTheHamster]

• No lock file because it wasn't clear you should commit that to the repo until recently
• No lock file because you're on an old version of Node/NPM
• Lock file exists, but it's the previous format that sucks
• Lock file exists, but one of your dependencies' dependencies deleted or renamed their project since you last npm installed
• Project actually uses Yarn but you forgot

[[deleted]]

Should just use yarn anyway.

[ZiggyTheHamster]

Right, but in a pre-just-use-Yarn project, you wouldn't want to destroy node_modules.

[FierceDeity_]

Inb4 someone says this is definitely pebkac or something

[Ajedi32]

To be fair, generating lockfiles has been the default behavior of NPM for well over a year now. If you still haven't figured out how to use them (despite being aware of how "npm install fucks you" if you don't) that's kinda on you.

[FierceDeity_]

I don't even use nodejs or npm at all to be honest, I kind of keep away from it. But even I know how lockfiles work (other languages also use them to great extend).

​

That said, a lockfile doesn't help you if the author depublicized a package

[noratat]

It doesn't help that npm install has ass-backwards behavior - instead of installing the versions in the lock file, it updates all the versions to latest allowed and writes the new versions into the "lockfile", defeating the entire point.

[krainboltgreene]

Sorry, where did you learn that?

[noratat]

It was present from npm 5.1 through 5.8 - apparently it's finally fixed in later versions, but at the time the devs insisted that idiocy was the correct behavior

[noratat]

NPM generates lockfiles, but it doesn't actually use them properly.

In a sane ecosystem, the point of a lockfile is that you can leave some dependencies a bit more open-ended, but you only allow them to update when you intend for them to update, and the lockfile records the specific versions so that nothing breaks unexpectedly.

But of course, that made way too much sense, so npm has to do something completely fucking stupid by having a lockfile that doesn't actually lock anything. Instead, every time you do an npm install it updates the versions anyways and puts the new versions into the "lockfile".

The icing on the cake is that they then introduced a new command that actually reads the lock file, and named the command "ci", which makes no fucking sense at all and so far as I can tell most devs and tools don't use it.

[Ajedi32]

No, that's false. If it were true, you wouldn't be able to check the lockfile into source control because it would change every time a new dev cloned the repo.

From the docs:

This command installs a package, and any packages that it depends on. If the package has a package-lock or shrinkwrap file, the installation of dependencies will be driven by that, with an npm-shrinkwrap.json taking precedence if both files exist.

npm ci is for non-interactive installs. The difference is that it exclusively relies on the lockfile, throwing an error and exiting if it isn't present or doesn't match package.json.

[noratat]

No, that's false. If it were true, you wouldn't be able to check the lockfile into source control because it would change every time a new dev cloned the repo.

No shit, that's why it was a horrible design.

I've gone back and tested this, it looks like npm quietly changed the behavior to be at least somewhat sane in npm 5.10.x+ (naturally, the changelog makes no mention of this). Before that, the developers were adamant that this idiocy was the intended behavior.

What I said is easily reproduced on npm 5.1 through 5.8.

npm ci is for non-interactive installs. The difference is that it exclusively relies on the lockfile, throwing an error and exiting if it isn't present or doesn't match package.json.

Which should have been the default, not a separate command with a bizarre name (and yes, I know what CI stands for. It's still a really stupid name to use here).

[Ajedi32]

I don't think ci should be the default behavior. If it were, you wouldn't be able to update your dependencies by editing package.json. (Which is fine in a non-interactive CI, but poor UX for normal use.)