4 ms·

So the cost is you add another tool (yarn) to your toolchain and this is better than NPM because your deps are all in one folder and just mapped through a heade

So the cost is you add another tool (yarn) to your toolchain and this is better than NPM because your deps are all in one folder and just mapped through a header file instead of being duplicated for every project, am I understanding that right?

zdragnar 5y ago
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`.
WorldMaker 5y ago
For what it is worth, npm v7 added "workspaces" ("monorepo") support (similar to yarn's) where all the node_modules are hosted a level higher in the folder tree and shared. https://docs.npmjs.com/cli/v7/using-npm/workspaces/ https://docs.npmjs.com/cli/v7/using-npm/workspaces/

zdragnar 5y ago

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`.

WorldMaker 5y ago

For what it is worth, npm v7 added "workspaces" ("monorepo") support (similar to yarn's) where all the node_modules are hosted a level higher in the folder tree and shared. https://docs.npmjs.com/cli/v7/using-npm/workspaces/ https://docs.npmjs.com/cli/v7/using-npm/workspaces/