Investigate Yarn 2

[Leksat]

1. Yarn 1 has issues with focused installs, while Yarn 2 supports them. Currently it's not really possible to install dependencies just for a single workspace. The current workaround is not good. With Yarn 2 it should be easy.

2. Yarn 2 has zero-installs feature. Would be nice to try it for this monorepo. Maybe it will speed up our workflows.

[pmelab]

There is one major blocker for this: Does Gatsby Cloud support Yarn 2?We have to try.

[dan2k3k4]

Not yet:
https://support.gatsbyjs.com/hc/en-us/articles/1500009113962-Does-Gatsby-Cloud-work-with-Yarn-2-

[pmelab]

Is yarn 2 backwards compatible? Can you install a yarn 2 project with yarn 1?

[Leksat]

Looks like it is.

Yarn 2+ creates a new file in the repository, e.g. .yarn/releases/yarn-3.0.0-rc.2.cjs. This file has to be committed into the repo. And it looks like this file is Yarn itself. So the globally installed Yarn is still version 1.

$ yarn --version
1.22.10
$ cd silverback-mono # Local version which uses Yarn 3
$ yarn --version
3.0.0-rc.2

[Leksat]

Another finding.

A project using Yarn 1 is just a set of files. With Yarn 2 it's more complicated. Tricks like the following one do not work anymore.

silverback-mono/packages/npm/@amazeelabs/scaffold/test.sh

Lines 14 to 18 in 62a21c1

	# Initiate a new node package.
	yarn init -y
	# Install the scaffold package.
	yarn add ../

Yarn 2 knows that the parent dir is a workspace belonging to silverback-mono. It can't just take it out of the monorepo and errors:

Usage Error: The nearest package directory (~/work/silverback-mono/packages/npm/@amazeelabs/scaffold/test) doesn't seem to be part of the project declared in ~/work/silverback-mono.

- If the project directory is right, it might be that you forgot to list packages/npm/@amazeelabs/scaffold/test as a workspace.
- If it isn't, it's likely because you have a yarn.lock or package.json file there, confusing the project root detection.

It's solvable of course. But just something to keep in mind.

[Leksat]

#658 uses Yarn 2 with nodeLinker: node-modules. I made it this way because the default Plug'n'Play mode requires to much of effort just to make yarn install work.

I checked yarn install time:

	Yarn 1 (dd61f6f)	Yarn 2 (eb3bd9c)
no caches	157s	319s
clean repo	126s	157s
re-run	56s	9s

Yarn 1 is faster 😅

Yarn 2 is faster in re-run just because it does not run prepare scripts for some reason. But it runs them on a clean repo.

Other findings:

• Yarn 2 patches TypeScript to be compatible with its PNP mode. When a new TypeScript version is released, it can happen that Yarn's patch does not apply anymore ([Bug] Cannot install typescript 4.3.2 with yarn 2 / node_modules linker yarnpkg/berry#2935)
• Yarn 2 patches TypeScript even if PNP mode is disabled.
• Yarn 3 will be released soon. It's RC2 at the moment.

I would stay on Yarn 1 for now. Yarn 2 with nodeLinker: node-modules gives no benefits. PNP mode has a great idea behind, but currently it's difficult to migrate to it. Let's wait for microsoft/TypeScript#35206 at least.