Yarn 1.0: Workspaces, auto-merging lockfiles, selective versions resolutions
code.facebook.com
code.facebook.com
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 great job.
* https://stats.yarnpkg.com * https://brew.sh/analytics/install-on-request/
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 quickly. [1]
If yarn had been approached with more senior developers I think it could have replaced npm entirely.
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.
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.
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 codebase quality means that future features will take too long to build.
Shared modularized code without creating private npm packages or doing some "linking" magic has been wonderful for productivity. It's as simple as creating another local package and symatically everything else has remained the same as a regular npm package, plus the benefits of having immediately updating code. For anyone with a large modular codebase wanting to forray into a monorepo approach I highly recommend checking it out. They also released a blog post here detailing the feature: https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
The barrier to mono repo seems to have always been the need to create massive amounts of bespoke tooling to handle the build pipelines(how do I build just this proj?, how do I run tests on just this proj?, how do I build just this proj and its deps?, etc). These are totally solvable with dedicated dev resources, but these are typically the problems you try to avoid rather than spend time on at a lot of companies; say < 1k engineers(snark).
Workspaces and Lerna seem to be a small piece of the puzzle even if critical. Are there tools to help out with rest? For instance if I'm using Bitbucket pipelines, what should I be looking for to help building from a mono repo?
This is a giant blind spot in Git, and none of the proposed workarounds come anywhere close to the tiny cognitive load of svn's answer to this problem.
But nobody on the git design committee seems to give a shit about cognitive load, so I'm probably just shouting into the tempest.
That being said - I have migrated to it completely on all projects and never looked back - so yay for yarn!
https://github.com/heroku/heroku-buildpack-nodejs/issues/468
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.
[1] https://github.com/nodejs/docker-node/pull/337 [2] https://github.com/nodejs/docker-node/pull/403
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.
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.
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.)
Meanwhile ... I do regret that this doesn't introduce alternative dependencies, like Debian packages have, where your package foo can have dependency on "either bar or baz". Oh well.
Competition is good, and having 2 implementations of the same basic idea that each prioritise different things means that more people can have their cake and eat it too.
Having one tool that has hundreds of flags to enable different use-cases is an anti-pattern in my opinion, and a fantastic alternative is to create multiple competing tools that each handle those different use-cases. It's the unix philosophy taken to the extreme, each "program" should do one thing, and do it well.