Committing .yarn directory to git when using yarn berry

Question

In the next version of yarn ("berry") the manual states that one should just commit the directory created called .yarn, but if you use the multi-version setup for yarn, this directory contains the file releases/yarn-berry.js which seems to be the entire berry version of yarn, taking up more than 2MB of disk.

This just seems really wrong - why should I commit a package manager to git, just to get it to work?

Crissman

Many people aren't happy with yarn berry. I just stay with classic yarn / npm. This new version of yarn makes things more complicated :/ – Lemnos

Thanks, @Konrad. Do I know you? – Crissman

This concept reminds me of the Gradle wrapper. A simple lock file with a version reference and hash so that yarn can bootstrap from state zero and fetch the scripts - that would have been the straightforward choice. No idea why they thought it would be wise to spam commits with their dependencies. This is meant for deployments but not for version control. – Paramedical

Answer 1

The new docs states using node's newest corepack feature (to date).

This means that when using appropriate node you only need to place a valid packageManager field value in package.json and run corepack enable, e.g.

{
  "name": "foo",
  "packageManager": "[email protected]",
  "scripts": {
  ...
  }
}

Chane

It sounds as if they have replaced the approach with something more sane. – Crissman

Answer 2

The Yarn developers explain the rationale for this in the Installation docs, in the section called "About global installs":

Using a single package manager across your system has always been a problem. To be stable, installs need to be run with the same package manager version across environments, otherwise there's a risk we introduce accidental breaking changes between versions - after all, that's why the concept of lockfile was introduced in the first place! And with Yarn being in a sense your very first project dependency, it should make sense to "lock it" as well.

Once Yarn is tracked and "locked" as a per-project dependency, it ends up getting committed to Git if you follow Yarn 2's zero-install strategy, the rationale for which is explained here.

I'm a newcomer to Yarn, but I spent years working devops, helping developers figure out why their code would sometimes build correctly on half of the team's laptops but not on the other half, or would suddenly start failing to build in CI while continuing to work elsewhere. Trying to keep the version of npm consistent across every computer and codebase in the company was essentially impossible, given that Node is constantly being upgraded, but locking each project to its own specific version of Yarn -- which, by being committed to Git, is guaranteed to be available in every checkout of that project -- solves this problem.

Audiometer

i find this default approach really bizarre. i don't want yarn to be part of my project, i'd rather that it was a system dependency. why can't yarn just write the version to the yarn.lock, and then automatically try and use that version if it's available or throw an error/warning if not. – Epistemology

I don't have time to do the research, but I believe if you disable Yarn's "zero-installs" you'll get behavior like what you describe. Not sure if Yarn will warn you, but you could write a script for that. But what will happen is that Yarn will update, your build script will immediately break everywhere, and you will have an emergency task to upgrade Yarn on every developer box and build system. I've been there! – Audiometer

@MikeCampbell yarn should be part of your project just like anything else you use including eslint and others. Different projects have different dependencies, and you need to ensure you're using the right configuration for that particular project. As someone who frequently changes between projects, it's incredibly difficult to switch around when dependencies (like yarn or npm) aren't properly tracked for that project. – Ayeshaayin

Recommendation to store 3rd-party binaries in repo - is a red flag for me - a second one for yarn in particular, after the first being their recommendation to store fetch cache in repo for zero install. – Pumpkin

Answer 3

The official documentation mentions what's should be ignored and what should be committed. It can solve this problem I think. https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored

Nicaea

I saw this page and it says that you should commit the yarn2 code. That doesn't make much sense imho. – Crissman

Answer 4

I have written a small tool for those people who don't want to commit Yarn 2+ binary into their git repos, while still benefiting from sticking Yarn version per project. If you already have Yarn 2+ configured in your project just don't want to commit it, you can run:

yarn dlx pinyarn

This command will generate .pinyarn.js (4KB) which you should commit, instead. .pinyarn.js will contain URLs inside to download Yarn 2+ and its plugins from the official Yarn Berry GitHub repo. .pinyarn.js will download binary and plugins from these URLs if they are not downloaded yet.

You can also specify which version of Yarn 2+ you want via:

yarn dlx pinyarn 3 - the latest released Yarn 3 version, or

yarn dlx pinyarn 2.2.2 - version 2.2.2, or

yarn dlx master - version from latest sources, or

yarn dlx 1638 - version from Pull Request 1638

The pinyarn tool repo on GitHub: https://github.com/sysgears/pinyarn

Nonsectarian

It's great that you're doing something, but until it's apparent why yarn requires this in the first place, then I'll wait using your workaround. – Crissman