chore: migrate to Yarn Modern

[RDIL]

Motivation

Switch to yarn v3

Have you read the Contributing Guidelines on pull requests?

yes

Test Plan

i'm not done yet

Related PRs

slorber/responsive-loader#1

[Josh-Cena]

Context: RDIL and I had been talking about this on Discord. We both investigated in Yarn berry in the past week, but ran into some problems due to our monorepo setup. Seems he's more experienced in this, so I let him champion this migration.

[netlify[bot]]

✔️ [V2] Built without sensitive environment variables

🔨 Explore the source changes: 6ff7234e9e4e9a14b6923521c41aa61382128722

🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/61f39c28b8e6a10008c7c7bf

😎 Browse the preview: https://deploy-preview-6028--docusaurus-2.netlify.app

[github-actions[bot]]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟠 Performance	67
🟢 Accessibility	100
🟢 Best practices	100
🟢 SEO	100
🟢 PWA	92

Lighthouse ran on https://deploy-preview-6028--docusaurus-2.netlify.app/

[Josh-Cena]

Now we got it sorta running😄 Next we'll focus on the publish

[Josh-Cena]

Hmmm! Blocked on https://github.com/preactjs/compressed-size-action/pull/41... We may need to re-implement that action ourselves

[merceyz]

That shouldn't be an issue anymore, the problem is that it runs the following invalid command

yarn --frozen-lockfile run build:website:en

[Josh-Cena]

Yes, but in the action it's like this:

https://github.com/facebook/docusaurus/blob/fb6393fdcea93d8fc7cc69a7c3ed845e60905e7f/.github/workflows/build-perf.yml#L25-L32

I assume the rest comes from the action

[RDIL]

Why go back to lerna?

[Josh-Cena]

Why go back to lerna?

I had a feeling that it would work😄cf https://github.com/facebook/docusaurus/pull/6028#discussion_r762302421

If you want to still use monodeploy just revert the last two commits. At least I've got the E2E tests running, we are one step closer

[RDIL]

I'd probably suggest using monodeploy (since lerna as a tool seems to not be built for what yarn berry does), but it's up to y'all to decide.

[slorber]

Hi there

Just to be sure, apart from staying up to date and upgrading to Yarn v3 (which IMHO we should do, but maybe not now?), I have some questions:

• What problem are we trying to solve here
• What are the immediate benefits from this migration?
• What are the problems with Lerna we currently have, justifying to replace/remove it?

I'm not saying we shouldn't do it, just trying to understand better.

I'd like to focus on v2.0 and migrating to Yarn 3 (that I don't really know and can't review easily) doesn't seem like a top priority for that goal, so it may be better to consider this PR is a POC for now, that we can continue later once v2.0 is released.

[RDIL]

To quote the Yarn website:

In a few words, upgrading to the latest versions is critical to a fast and stable Yarn experience. Numerous bugs were fixed since the first major version, and we no longer expect to build new features on the old trunk. Even if you don't plan to use the new default installation strategy called Plug'n'Play your projects will still get benefits from the upgrade:

• The good old node_modules installer improved as well as various edge cases got fixed
• A renewed focus on performances and good practices (we now formally track perfs via a dashboard)
• Improved user experience for various CLI commands and settings (yarn add -i, yarn up, logFilters, ...)
• New commands and capabilities (such as the TypeScript plugin, or the release workflow)

And of course a very active development cycle.

LONG VERSION

While the Yarn Classic line (1.x) remains a pillar of the JavaScript ecosystem, we recommend upgrading if possible. Why's that?

New features: On top of the classic features you're already used to, on top of the new ones you'll discover (yarn dlx, builtin patch: protocol, ...), Modern offers plugins extending Yarn's featureset with changesets, constraints, workspaces, ...

Efficiency: Modern features new install strategies, leading projects to only be a fraction of their past self; as an example, under the default configuration the stock CRA artifacts now only take 45MB instead of 237MB. Performances were improved as well, with most installs now only taking a few seconds even on extremely large projects. We even made it possible to reach zero seconds!

Extensibility: Modern's architecture allows you to build your own features as you need it. No more of you being blocked waiting for us to implement this feature you dream of - you can now do it yourself, according to your own specs! Focused workspaces, custom installs, project validation, ...

Stability: Modern comes after years of experience with maintaining Classic; it allowed us to finally fix longstanding design issues with how some features were implemented. Workspaces are now core components, the resolution pipeline has been streamlined, data structures are more efficient... as a result, Modern is much less likely to suffer from incorrect assumptions and other design flaws.

Future proof: A big reason why we invested in Modern was that we noticed how building new features on Classic was becoming difficult - each change being too likely to have unforeseen consequences. The Modern architecture learned from our mistakes, and was designed to allow us to build features at a much higher pace - as evidenced by our new gained velocity.

[Josh-Cena]

maybe not now?

It's now or never. We aren't blocked by anything; Yarn v3 is fully stable. This is also internal so there's no release schedule / pressure from users, but it's better if we start doing something

[slorber]

Thanks

I understand these advantages, but this looks more like an internal quality of life improvement than a critical thing we need asap.

It's now or never.

I don't really understand what you mean. What prevents us to do this upgrade after 2.0?

If we work on this now, this delays 2.0 due to reviewing this PR, ensuring the release process still work as before, the changelog (using lerna-changelog) can still be generated, the canary releases keep working, and various other things that I may not think of.

If it's clear that all the work is done up-frontand well-tested in this PR, including a full release workflow, it's more likely to be merged as it's less likely that this becomes a time sink for me due to unplanned issues

TL.DR: the most important for me is a good step by step test plan that I can simply unroll to be 100% sure that everything will work after merge

[Josh-Cena]

I understand these advantages, but this looks more like an internal quality of life improvement than a critical thing we need asap.

Indeed. It's just internal; there's no release schedule. It doesn't block the v2 official release and you shouldn't stress about reviewing it. We're just keeping it here so people know that there's a work in progress. Everything else can move on.

It's now or never.

I was saying that "maybe not now" is not adequate because if there's a motivation and nothing's preventing us from doing it, we should do it rightaway, otherwise it would stay in the backlog forever.

Anyways, @slorber don't worry too much about this, @RDIL and I will need to make it production ready first before marking it as ready for review.

[Josh-Cena]

@merceyz We are currently using Yarn canary, but the build size report action is still failing when running yarn --frozen-lockfile run build:website:en. Is https://github.com/preactjs/compressed-size-action/pull/41 really not needed?

[Josh-Cena]

Summary of the workflows we need to check:

• Canary release, currently done with yarn lerna version `yarn --silent canary:version` --exact --no-push --yes && yarn lerna publish from-package --dist-tag canary --yes --no-verify-access
• E2E test with Verdaccio, currently done with npx --no-install lerna publish --exact --yes --no-verify-access --no-git-reset --no-git-tag-version --no-push --registry "$CUSTOM_REGISTRY_URL" "$NEW_VERSION"
• yarn workspaces foreach doesn't seem to output progress? Lerna tells me that it's currently executing script in workspace X, but Yarn workspaces just goes silent for two minutes

[merceyz]

@merceyz We are currently using Yarn canary, but the build size report action is still failing when running yarn --frozen-lockfile run build:website:en. Is preactjs/compressed-size-action#41 really not needed?

Sort of, its change from --frozen-lockfile to --immutable is unnecessary now but the part that fixes the npm variable is needed

- installScript = npm = `yarn --frozen-lockfile`;
+ npm = `yarn`;
+ installScript = `yarn --frozen-lockfile`;

yarn workspaces foreach doesn't seem to output progress? Lerna tells me that it's currently executing script in workspace X, but Yarn workspaces just goes silent for two minutes

Add the -i flag to see the output in real time and the -v flag to prefix each line with the workspace.

[Josh-Cena]

Add the -i flag to see the output in real time and the -v flag to prefix each line with the workspace.

Thanks! Just curious, is there a way to configure this in .yarnrc?

Sort of, its change from --frozen-lockfile to --immutable is unnecessary now but the part that fixes the npm variable is needed

That means a fix is still needed for this action. I see.