3 ms·

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 as

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.

errantspark 5y ago
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.
- zdragnar 5y ago
  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.
Zababa 5y ago
> Even with a package lockfile, npm couldn't do that. NPM now has npm ci (which I think should be the default) for that.
- zdragnar 5y ago
  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?
  - mmis1000 5y ago
    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`.

errantspark 5y ago

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.

zdragnar 5y ago
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.

Zababa 5y ago

> Even with a package lockfile, npm couldn't do that. NPM now has npm ci (which I think should be the default) for that.

zdragnar 5y ago
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?
- mmis1000 5y ago
  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`.