Hacker News Reader

Comment by zdragnar | Hacker News Reader

For a good while most people were better served by yarn anyway. I don't know exactly the current state of npm, but part of yarn's draw (even prior to the pnp aspect) was having deterministic builds. Even with a package lockfile, npm couldn't do that.

View on HN

> Even with a package lockfile, npm couldn't do that.

NPM now has npm ci (which I think should be the default) for that.

Is there a way to install another package / add one to package.json and update the lockfile while otherwise preserving the behavior of running npm ci?

If so, ignore this, but if not, wouldn't adding a new package have all sorts of weird side effects from miscellaneous updates to irrelevant existing dependencies?

It is the default.

So it ends up with un-optimized structure sometimes. Because the top package is locked and does not meet the version new package required.

In order to satisfy the constraint. Npm will install second copy of the package in nested directory.

And npm also have a `dedup` command for you to `screw it, change the version in lock and merge them if possible`.

Ahh, interesting, I wasn't aware of that issue. Personally the problem with npm for me has never been "the node_modules directory is too big" or "npm is non-deterministic" but rather "the quality of other people's code is terrible" or "this library solves 99 other cases in addition to the one I care about".

I think if you're careful about what you pull in from npm it's totally fine.

Having deterministic builds is a godsent boon in an ecosystem without proper semantic versioning enforcement. The fact that minor version number changes can be breaking means that every build can break (a bit tautological but a point worth emphasizing).

I also dont like that some packages are too big, or too small, or have too many transitive dependencies. It is a fact of life in npm land, though, making deterministic builds simultaneously minor and significant.

Reply on news.ycombinator.com