Jan Krutisch, Co-Founder at Depfu

We’ve been dancing around supporting Yarn 2 aka Yarn Berry for a while now because adoption seemed not to be there. It looks like that has changed.

We’ve now launched support for Yarn Berry and the important bit here is that we only support v3 and not v2. Yarn 3 has some command line switches specifically designed to support things like Depfu and that allowed us to build a much simpler version of Yarn support than what was possible before. Given that Yarn 3 has no additional drawbacks over Yarn 2, we think that migrating should be not a huge issue for most teams.

Our support for Yarn 3 is not complete, unfortunately:

  • Depfu will not maintain offline caches for zero install.
  • We will load patches, but we don’t support updating patched dependencies.
  • We don’t support constraints right now.
  • We do honor the vendored version of Yarn and vendored plugins. We do not support any specific plugins beyond simply providing and loading them.

What about zero install?

From the looks of it, this seems to be one of the more desirable features of Yarn Berry. For us, supporting the offline cache that’s the basis for zero install is, unfortunately, at least currently, sitting between “very hard” and “impossible”. Here are some reasons for that:

With Yarn Berry, updating the offline cache is unfortunately not as easy as with other package managers, as Yarn repackages every dependency in a different, probably slightly more efficient format, which means that Yarn actually needs to be involved. For other package managers, we simply download the packages from the registry and sort them into the git branch we’re working on.

Unfortunately, the Git Data API of GitHub, which we use for constructing the commit for an update, has some hard limits of how big a commit can be. We’ve run into this limitation already with Bundler, but given how large changesets for Yarn dependencies can become, we’re pretty sure we’ll run into this limit quite often. Fixing this would mean to completely rewrite the way we’re interacting with GitHub. That would not only be a very big, complicated change, but also would be much more expensive in operations.

A slightly dirty workaround

What we’ve told a couple of clients when we asked them to test Yarn 3 support is to handle this in a CI step that runs after Depfu. This is not a great solution because it messes with Depfu rebases, as we only rebase PRs that are not touched by other people’s (or robots) commits. But it does work and maybe we would even be able to support that with a bit of extra code so that these CI commits can be ignored and we could still run rebases. Let us know if you want us to try that.

Worth the upgrade?

Yarn Berry is a bit of a weird one. The engineering feels very solid and some of the ideas are really quite good. From a personal standpoint, having dealt with it during our implementation and testing phases and having read a lot of documentation, Berry feels a bit over-engineered, though.

I may be totally wrong and it could be that especially for larger teams and more complex setups, all the extra complexity is worth it, but there are a few things that I am really skeptical about. Having a generic plugin interface in a package manager sounds like a great idea, for example, but all I see is a bunch of extra complexity that might come to bite you at the most inconvenient moment in the future.

To me, and I am ready to admit that as a developer on Depfu I may have a unique perspective, package managers should be, as the saying goes, as simple as possible, but not simpler. They should focus on simplicity first and then performance. Yarn Berry errs on the side of trying to enable everything that anyone ever could want from a package manager.

That being said, I am very happy that the Yarn Berry team thought of the robot factories and specifically added options to support automated dependency updating. Integrating Yarn 1 has been quite a challenge and requires some really weird pieces of code.

Given that Yarn 1 is in sort of a “bugfix only” mode by now, I think it makes sense to migrate away from it in the near future. That could mean migrating to Yarn Berry, but of course it could also mean migrating to a current version of npm, since npm by now supports most of the Yarn exclusive features such as workspaces (and we’ve recently updated our npm integration to support them).