3 ms·

Wow, bold statement. Can you give examples of things it does wrong?

danielheath 5y ago
I can. In most ecosystems, I can share package sources between a VM and a host. npm shares mutable content (eg compiled artifacts) with package sources in `node_modules`. That breaks a ton of workflows that are common in other ecosystems. For instance, in ruby apps using bundler, I can commit my dependencies in vendor/cache; there are no network dependencies other than fetching the source code. That makes turning code into a running server faster and more reliable. Go supported the same thing from v1 via GOPATH (because that's how google runs their repo). Commit your dependencies and carry on (go had different shortcomings in dependency management in those days). This feature turns things like `left-pad` from a fiasco into a non-event. Also, it took npm years to implement a lockfile, only for most npm commands to disregard it. I used to frequently get versions other than the one I wanted. It's been ~6 years since I switched away so it may have improved since then. After my experience using npm I fundamentally do not trust the brand, and until yarn screws up I have no reason to give npm another chance.
- lhnz 5y ago
  There's nothing stopping you from running `npm` or `yarn` offline and committing the cache. In fact, both of these package managers have had direct support for this workflow since 2016 (https://docs.npmjs.com/cli/v7/using-npm/config#offline https://docs.npmjs.com/cli/v7/using-npm/config#offline) and 2017 (https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/ https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/) respectively.
  - rlkf 5y ago
    Except that the format of the npm cache is version-specific. You would probably be better off using https://github.com/heikkipora/registry-sync https://github.com/heikkipora/registry-sync instead.
rlkf 5y ago
`npm uninstall foo` simultaneously upgrades all the _other_ packages. Experienced developers they are not.

I can. In most ecosystems, I can share package sources between a VM and a host. npm shares mutable content (eg compiled artifacts) with package sources in `node_modules`. That breaks a ton of workflows that are common in other ecosystems. For instance, in ruby apps using bundler, I can commit my dependencies in vendor/cache; there are no network dependencies other than fetching the source code. That makes turning code into a running server faster and more reliable. Go supported the same thing from v1 via GOPATH (because that's how google runs their repo). Commit your dependencies and carry on (go had different shortcomings in dependency management in those days). This feature turns things like `left-pad` from a fiasco into a non-event. Also, it took npm years to implement a lockfile, only for most npm commands to disregard it. I used to frequently get versions other than the one I wanted. It's been ~6 years since I switched away so it may have improved since then. After my experience using npm I fundamentally do not trust the brand, and until yarn screws up I have no reason to give npm another chance.

lhnz 5y ago
There's nothing stopping you from running `npm` or `yarn` offline and committing the cache. In fact, both of these package managers have had direct support for this workflow since 2016 (https://docs.npmjs.com/cli/v7/using-npm/config#offline https://docs.npmjs.com/cli/v7/using-npm/config#offline) and 2017 (https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/ https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/) respectively.
- rlkf 5y ago
  Except that the format of the npm cache is version-specific. You would probably be better off using https://github.com/heikkipora/registry-sync https://github.com/heikkipora/registry-sync instead.

rlkf 5y ago

`npm uninstall foo` simultaneously upgrades all the _other_ packages. Experienced developers they are not.