DEV Community

Yarn and the dark future of third party NPM clients

Lou (🚀 Open Up The Cloud ☁️) on October 01, 2019

Yarn doesn't handle the underlying NPM infrastructure with elegance — and it might never do so. I’ve spent the last few days wrangling with Yarn e...
Collapse
 
arcanis profile image
Maël Nison • Edited

Howdy! I'm Yarn's maintainer 🙂

It's an interesting article - here are some insight I can provide. Keep in mind I'm a bit biased, of course!

But the problem is not (only) that Yarn code is buggy — the problem is more the disconnect which exists between Yarn (the client) and NPM’s infrastructure

First, consider that the Yarn v1 codebase was written in a quite different time. The team changed, new major features got released (such as workspaces), and even the way we write Javascript shifted! Lots of its internals would be designed differently if we had the chance... And that's precisely what's happening!

But no amount of features in yarn 2.0 is going to fix the disconnect between NPM and the Yarn client

The v2 effort you reference is an acknowledgement that Yarn wouldn't have been able to continue forever in its current state. It represents the new, more stable and mature foundation which will give us the tools to maintain Yarn for the foreseeable future.

No amount of feature is going to fix the design issues, that's true. Fortunately, we're on both fronts! It's an incredible amount of work, but the results are showing. Writing features and fixing bugs has never been so easy.

Which means that Yarn will always lag behind NPM on adopting any necessary client changes that are based on CDN changes.

I don't think that the registry is constraining us in any way. Something nice with the open source is that prioritization is a default: if something is important, someone will work on it. With the v2 plugin system this will become even more true, as users won't have to be synced with our releases to integrate third-party features into their projects.

it doesn’t help that important players such as Github are choosing to prioritise the NPM client instead instead of the Yarn client.

I wouldn't say that Yarn is "ignored". We have good relations with many other projects and companies. I met with the GitHub folks a few times, and while we didn't discuss this particular issue I know they have an eye on Yarn.

It seems without some changes to the way the ecosystem works that third-party clients are doomed to have a second-rate

I'm not too worried about this in particular. I think the key question will be how easy it will be for our open source contributors to work with us. By making the codebase more approachable, I'm certain we have a bright future ahead of us.

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️)

Hey Mael!

Thanks very much for your time and your insight, I knew writing this was a risk, since theree was a lot that I did not know. But I felt it important to open up a conversation on the topic, and I'm glad that despite the points I raise you feel hopeful V2 will address a lot of these issues. It seems V1 served it's purpose in showing that package management could be done better, and hopefully V2 will do the same all over again. I'm quite excited for the modules, and the concept of running Yarn as an API, too.

The majority of what I discuss is merely from digging around in the past few days. I was also conscious that I didn't want to downplay all the hard work that goes into open source, and how grateful I always am for the maintainers like yourself — so thank you!

Collapse
 
thenakedthunder profile image
thenakedthunder

I wanted to give you a feedback on this. I also have problems with yarn always hanging up at different cases like running tests, removing or installing a package etc. The problem is I am very bad at package management, and I know it is the reason for at least half of my problems here. But I want to code, not to manage packages. Yet a lot of my precious free time (it is a hobby project) is wasted because of things like that. I really want to use this time to code. I decided to move back to npm. If things go wrong there, at least there is an error message I can use to try to find the problem.

I wanted to share this as a feedback. If you can get some use cases or a 'user persona' from my story that you can build on, please go for it. I mean it, since there was a good reason I switched to yarn in the first place, and there is a great chance I will come back. Especially if your team keeps up the hard work, and make this a better experience for users.

Collapse
 
byrro profile image
Renato Byrro

Very informative, thanks for sharing.

You said in the beginning that:

"the problem is not that Yarn code is buggy"

But why wouldn't you consider this a buggy behaviour?

"if the CDN fails in unpredictable ways (...) the Yarn client is not appropriately handling these cases".

Personally I would say that's a bug. Even if npm returns a totally new error out of a sudden, yarn must have an implementation that allows itself to fail gracefully, without leaving the user in the dark.

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️)

Ah — good spot Renato!

I think I mean to say "the problem is not only that yarn is buggy". The point here I want to stress is less that yarn has bugs — which are temporary and can be fixed. But more that these problems have been going on for years and we have no clear way that they'll go away, with any amount of bug fixes.

I'll make a quick edit!

🙏🙏🙏🙏🙏

Collapse
 
byrro profile image
Renato Byrro

That makes sense! ;)

Collapse
 
anwar_nairi profile image
Anwar

Great article, lights out some parts of Yarn I did not know before, very instructive.

I might say, managing relatively small projects, that Yarn never failed me since I switched to using it. I like the speed of installation and upgrade. The fact you do not have to append "run" before each of your scripts is making me earning some few milliseconds but can make the difference if I make several installation in my day.

Collapse
 
losd profile image
Dennis Du Krøger

That Github issue seems more like a Yarn problem than a Github problem. If you're going to be an NPM client, you better make sure you accept what NPM accepts. It would have been a quick "fix your client" from me too, and I can't really see that being an example of ignoring anything.

Collapse
 
ducksauce88 profile image
ducksauce88

For me, using CRA I had some issues getting up and running. Using yarn resolved my issues and I've been using it without any problem since.

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️)

Glad to hear it! We're running yarn in some production build systems that are running hundreds of times a day, and some pipelines currently run yarn install ~100 times a build. In a day we probably go through thousands, if not more installations a day. I guess on larger scale, problems surface faster!

If it works for you, and you like it — go for it! I'm not bashing Yarn or it's capabilities, more highlighting some difficulties we face as an ecosystem! :)

Collapse
 
ducksauce88 profile image
ducksauce88

Oh I know you're not bashing it! Yes I'm using it on a MUCH smaller scale.

Collapse
 
walialu profile image
Marco Kellershoff

I simply can't live without yarn's offline mirror capability 😢

Collapse
 
adesombergh profile image
Aldebaran Desombergh • Edited

Your title talks about "third party NPM clients" but in the end you just talk about Yarn?
I mean you take one example (not sure it's a good one) and make it a rule?

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️) • Edited

I'm simply trying to highlight some difficulties in the infrastructure that makes it difficult for third parties to compete. There aren't so many more to speak of (except github.com/pnpm/pnpm) so to speak, but that's the premise of the article.

Collapse
 
raulmarindev profile image
Raúl Marín

Hi Lou, did you start using Yarn v2 already?