4 ms·

What was the compelling reason to make Yarn instead of contributing to npm, perhaps ownership? Seems like they could given everyone a lot of improvements and i

What was the compelling reason to make Yarn instead of contributing to npm, perhaps ownership? Seems like they could given everyone a lot of improvements and instead they fractured the market a bit.

sotojuan 9y ago
npm code is a mess and contributing to it is a very slow process. Competition from yarn led to npm quickly adopting lockfiles and being faster.
brentvatne 9y ago
I can't speak to the original intentions of the authors, but I suspect it might be related to difficulty of making significant changes to the project due to some strongly held beliefs. An example: react-native depends on alpha/beta versions of react, and libraries in the react-native ecosystem tend to include a peer dependency on react (eg: react >= 15). React 16.0.0-alpha.12 will not satisfy this range, but 16.0.0 will. It's unclear to me in what way it is useful to exclude pre-release versions, and this causes a lot of confusion for users. I posted about it here: https://github.com/npm/npm/issues/8854 https://github.com/npm/npm/issues/8854 and it was shutdown for ideological reasons, rather than practical considerations. On the other hand, someone submitted a patch to yarn to improve this behaviour and it was quickly accepted: https://github.com/yarnpkg/yarn/pull/3361 https://github.com/yarnpkg/yarn/pull/3361.
- Klathmon 9y ago
  And it wasn't all just "strongly held beliefs" there were very real problems with upgrading parts of npm. npm for a long time was built to do what npm did. There was no spec, no "rules" it did what it did, and changing that behavior was a breaking change. Everyone could agree that feature X needed to be fixed or redone, but doing so would break a significant number of packages/projects so it wasn't done. Yarn was the solution, they could start from scratch, not worry about those older/undocumented/arcane edge-cases. They didn't have to care about backwards compatibility, or even reimplement the same API. Every time this question is asked, I also like to point out that many of the Yarn devs were npm devs, and the project as a whole not only had the "approval" of npm, but also was in-part encouraged by them. Competition is good, and it's "the javascript way" to have multiple competing tools that each prioritise different things. Yarn is pretty much a perfect example of that.
Lazare 9y ago
Although there have been marked improvements recently, the npm project has been crippled by politics. Much of what yarn fixed were issues that technically could have been easily fixed in npm, but could not be due to political concerns. For example, the npm project was reluctant to make any changes that broke backwards compatibility, even when the existing feature was outright unusable (eg, shrinkwrap). By contrast, Yarn was free to break backwards compatibility since it was a new project, and it's popularity, in turn, allowed npm to finally feel free to start fixing things. Yarn has helped npm hugely in my view, but it was only able to do so as an independent project. The current version of npm has working lockfiles because Yarn shipped working lockfiles, but every proposal to fix them pre-yarn was shot down out of hand for (in my view) nonsense reasons. (This helps explain, incidentally, why yarn has had some much support from parts of the npm dev team. They knew, eg, lockfiles had to be fixed, and if it took yarn as a catalyst, so be it.)

What was the compelling reason to make Yarn instead of contributing to npm, perhaps ownership? Seems like they could given everyone a lot of improvements and instead they fractured the market a bit.

sotojuan 9y ago

npm code is a mess and contributing to it is a very slow process. Competition from yarn led to npm quickly adopting lockfiles and being faster.

brentvatne 9y ago

I can't speak to the original intentions of the authors, but I suspect it might be related to difficulty of making significant changes to the project due to some strongly held beliefs. An example: react-native depends on alpha/beta versions of react, and libraries in the react-native ecosystem tend to include a peer dependency on react (eg: react >= 15). React 16.0.0-alpha.12 will not satisfy this range, but 16.0.0 will. It's unclear to me in what way it is useful to exclude pre-release versions, and this causes a lot of confusion for users. I posted about it here: https://github.com/npm/npm/issues/8854 https://github.com/npm/npm/issues/8854 and it was shutdown for ideological reasons, rather than practical considerations. On the other hand, someone submitted a patch to yarn to improve this behaviour and it was quickly accepted: https://github.com/yarnpkg/yarn/pull/3361 https://github.com/yarnpkg/yarn/pull/3361.

Klathmon 9y ago
And it wasn't all just "strongly held beliefs" there were very real problems with upgrading parts of npm. npm for a long time was built to do what npm did. There was no spec, no "rules" it did what it did, and changing that behavior was a breaking change. Everyone could agree that feature X needed to be fixed or redone, but doing so would break a significant number of packages/projects so it wasn't done. Yarn was the solution, they could start from scratch, not worry about those older/undocumented/arcane edge-cases. They didn't have to care about backwards compatibility, or even reimplement the same API. Every time this question is asked, I also like to point out that many of the Yarn devs were npm devs, and the project as a whole not only had the "approval" of npm, but also was in-part encouraged by them. Competition is good, and it's "the javascript way" to have multiple competing tools that each prioritise different things. Yarn is pretty much a perfect example of that.

Lazare 9y ago

Although there have been marked improvements recently, the npm project has been crippled by politics. Much of what yarn fixed were issues that technically could have been easily fixed in npm, but could not be due to political concerns. For example, the npm project was reluctant to make any changes that broke backwards compatibility, even when the existing feature was outright unusable (eg, shrinkwrap). By contrast, Yarn was free to break backwards compatibility since it was a new project, and it's popularity, in turn, allowed npm to finally feel free to start fixing things. Yarn has helped npm hugely in my view, but it was only able to do so as an independent project. The current version of npm has working lockfiles because Yarn shipped working lockfiles, but every proposal to fix them pre-yarn was shot down out of hand for (in my view) nonsense reasons. (This helps explain, incidentally, why yarn has had some much support from parts of the npm dev team. They knew, eg, lockfiles had to be fixed, and if it took yarn as a catalyst, so be it.)