|
|
|
|
|
|
by brentvatne
3209 days 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 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. |
|
|
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.