[int_19h]

One of the basic features expected of a package manager is reproducibility (i.e. if two people build the same code with the same dependencies, it should produce the same result). On that count, npm is literally broken by design:

https://github.com/npm/npm/issues/10999

[allover]

Well no, installing 2 packages, one after the other from the command-line (as in that issue) is not the way you 'share builds' with npm. You do that via a package.json + 'npm shrinkwrap' "lockfile".

Shrinkwrap does have known issues (mainly w.r.t. platform-specific modules and verbosity), though I've never had any problems with it, but if you want a better lockfile I suggest the Yarn client.

(Believe Python's pip behaves similarly to npm in that issue).

I prefer Yarn's lockfile handling, but saying npm is 'broken by design' is wrong.

[int_19h]

There are evident security issues with this, as spelled out in the bug. Yeah, I'd consider that broken. Of course the repro is contrived, but it's not at all unusual to install some packages manually. The point is that once you do so, you might not get the same result later from package.json, either.

And yes, Yarn is the sane option for package management for Node. Why isn't it the default one yet?

[Can_Not]

> but it's not at all unusual to install some packages manually

If you're taking about deployments, that's definitely unusual. Outside of deployments, what's a scenario where deterministic builds are important, but it would be considered normal to manually install them anyways?

[int_19h]

I don't see why deterministic builds would only be important for deployments. Even ignoring the security issues here (which don't necessarily apply only to deployments), there's this whole classic "works for me, not a bug" situation.

[Can_Not]

> I don't see why deterministic builds would only be important for deployments.

Great, then you should be able to mention at least one solid normal usecase as an example. I don't think there is one.