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.
Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
21–30 of 48 posts
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#22Will Yarn ever be merged into npm's CLI? Why does the node community back two package managers?
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#23Earlier quoted context omitted.
Deletes them in what situation? Can you provide a link?
There's a couple of similar deletion issues, they're all linked from https://github.com/npm/npm/issues/17929 , the deleting private one happens in all situations, eg just an npm install, see https://github.com/npm/npm/issues/17927
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#24How soon will it be available via brew update?
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#25How soon will it be available via brew update?
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#26Earlier quoted context omitted.
> If yarn had been approached with more senior developers I think it could have replaced npm entirely. The biggest reason by far why Yarn got so popular so quickly was because it didn't come and try to split the existing ecosystem but chose build on top of npm's foundation with ways that npm didn't (at that point) offer instead.
Yes I agree! I didn't really make myself clear. I feel that if yarn kept its strategy but had more senior developers writing the core software I think it could have been able to outpace npm in terms of features and speed. If this had have been the case then it wouldn't make sense to use npm at all. Yarn would be faster and have more features. From my experience I feel that yarn isn't offering much value now and the c…
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#27A big congrats are in order. Yarn came out just as I started working in the node ecosystem, and it fixed nearly all my dependency manager problems. Since then it's evolved and it's really helped provide a counter to npm offering different design choices but working together where it counts. It's the 4th most popular brew dependency and ~25% of npm downloads. People love it. Congrats Yarn team - you've been doing a gr…
I jumped on node around the same time and I've come to an opposite conclusion. The things I liked was the offline cache and the yarn integrity. However there was just too many issues regarding its dependency on npm and not playing nice with other tools such as brew. I dove into the code to try and fix these issues but both the quality of the code base and the politics going on in the issue tracker turned me off very…
Some very senior developers were involved in it's development including the original author of Babel, someone who has been a core member of and contributor to jQuery, Rails, Rust & Ember, people who have/currently work on Chrome, Node core, etc etc etc.
If those people aren't "senior" developers, you're going to have to explain what you mean by that.
Also replacing npm means replacing npm as the bundled package management tool that comes with node, and likely replacing the fact that they use the npm registry.
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#28What 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.
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.
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#29Earlier quoted context omitted.
Deletes them in what situation? Can you provide a link?
There's a couple of similar deletion issues, they're all linked from https://github.com/npm/npm/issues/17929 , the deleting private one happens in all situations, eg just an npm install, see https://github.com/npm/npm/issues/17927
It's odd they haven't at least triaged the issue (but you know humans/time). That said the fact it's a niche workflow (it's unclear why the user is using --no-save) and the steps to reproduce won't be doable by the team ... probably doesn't help the issue get attention.
Re: Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
#30What 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.
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 w…
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.