Berry: [Bug] committing copies of large yarn artifacts to git

[mzedeler]

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?

[merceyz]

The package manager is essentially your first dependency, checking it into the repository ensures that everyone that works on that project has the exact same version of the CLI, this isn't V2 specific though, you can and should do the same for V1 projects.

Check here for a explainer for the different things to gitignore https://yarnpkg.com/advanced/qa/#which-files-should-be-gitignored

[mzedeler]

So any project using yarn should have an initial 2+MB large commit containing a verbatim copy of yarn? You can't be serious...

[arcanis]

@mzedeler there are other ways that we are exploring but that require support from other projects from the ecosystem. In the meantime, you can either do as we suggest, or instead put the binary in your home folder and reference it from there.

Please also be aware that sentences like "You can't be serious" don't really make us want to help you. We're doing the effort to understand your position and provide context, but that should go both ways.

[mzedeler]

Sorry - it just seems really excessive to copy a file of this size into the git repository. I am really curious what caused all other options to be ruled out. Wouldn't it be possible to keep yarn out of the repository and just output an error if it is incompatible with the one required by the code?

[matfax]

This is a serious issue. It's like a step backward from yarn classic. Why do lock files exist if yarn itself is not able to fetch its scripts automatically? This reminds me of the Gradle wrapper but it's worse because, unlike Gradle, yarn's commits are more than one line in a wrapper which will change with each version update. You'll see commits spammed over with yarn's scripts. Shared dependencies do not belong into version control. They belong in a lock file. Package managers have no privilege here. It's good to have the option for zero-installs when targeting deployments but this shouldn't be the default. You'll need to assume some degree of trust into the installed yarn package and the building system. The version of yarn2/berry could be given in its config separately. The version is even part of the script's reference path .yarn/releases/yarn-2.2.2.cjs. Please think about the consequences on repository load. 2MB+ is a lot. There should be an option to bootstrap yarn2 from 2 files, just as it is common for modern package managers such as yarn classic (i.e. one config and one lock file).