Description

Why upgrade from yarn 1.x (aka classic)?

Stability: Yarn Modern came after years of experience with maintaining Classic; its design was informed by the shortcomings we saw, and as a result the software is much more stable than it ever was.

New features: Yarn Modern provides many new features that didn't exist in Yarn 1.x - or any other package managers for that matter. As an example, Constraints are exclusive to Yarn Modern.

Flexibility: Yarn Modern supports all three installation strategies: Yarn PnP, node_modules, and via a pnpm-like content-addressed cache. No matter which one you prefer, you have it at your disposal.

Extensibility: Yarn Modern's architecture allows you to build your own features as you need it. No need to wait for us to implement this feature you hope for - you can now implement it yourself, according to your own specs, and use it straight away! Focused workspaces, custom installs, project validation, ...

Future proof: Yarn Modern was built after we started to see how difficult it was to build new features on Yarn Classic, with most changes having unpredictable consequences. This plateau has been solved, as evidenced by the slate of features that we released in the past few major releases.

My reasons for support an upgrade to Yarn Modern is it's tooling around monorepo management (see constraints, versioning, interactive upgrades, and a strong set of command-line tools).

Motivation and context

How has this been tested?

Setting up your environment:

1. corepack enable more detailed instructions
2. nvm use to ensure you are using the right version of node
3. yarn install - expect the output formatting to be quite colorful compared with yarn 1

Validate:

No command line regressions:

• yarn install
• yarn build
• yarn dev
• yarn start

The documentation pages for at least two other components are still loading, including:

• The pages render correctly, are accessible, and are responsive.

If components have been modified, VRTs have been run on this branch:

• VRTs have been run and looked at.
• Any VRT changes have been accepted (by reviewer and/or PR author), or there are no changes.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• If my change required a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.