Upgrade yarn to v3

[TheTrio]

This upgrades yarn from v1(yarn classic) to v3(yarn modern)

In order to update your local version of yarn, you have two options

Using NPM or another package manager

If you don't want to uninstall the current global `yarn` for some reason, you should update to the latest version of yarn 1. If installed via npm, do

npm i -g yarn@latest

Using Corepack

This is the way recommended by Yarn

Corepack is shipped by default in node 14.19.0+ and node 16.9.0+. In this case, you need not install anything. However, you should uninstall yarn if you installed it globally(via npm, homebrew or any other package manager)

For npm, run the following command

npm uninstall -g yarn

Then enable corepack

corepack enable

Now, you should have access to yarn.

And that's about it. The yarn command will use the binary present in .yarn/releases, ensuring that everyone has the same version of yarn.

[ragesoss]

Hmm... interesting.

Can you explain more about what each of the new files is for, where the relevant documentation is, and what the upgrade process for future versions of yarn will be?

It looks like this adds the yarn binary to the codebase... is that the only way to ensure consistent yarn versions? Also, is it necessary to guarantee that everyone uses the exact same version (as opposed to just a 'new enough' modern yarn version)? Are there other ways besides including the binary in the repo to get that consistency?

[TheTrio]

Can you explain more about what each of the new files is for, where the relevant documentation is, and what the upgrade process for future versions of yarn will be?

The migration guide can be found here.

Upgrading to future versions of yarn should be as simple as doing yarn set version stable.

As for the new files, the .gitattributes tells git to not keep track of diffs of the binary yarn files. The .yarnrc.yml is the config file for yarn - we need it for opting out of PnP mode(which gets rid of node_modules).

It looks like this adds the yarn binary to the codebase... is that the only way to ensure consistent yarn versions? Also, is it necessary to guarantee that everyone uses the exact same version (as opposed to just a 'new enough' modern yarn version)? Are there other ways besides including the binary in the repo to get that consistency?

I'm not sure but I think if everyone uses Corepack then committing the yarn binary won't be necessary. But Corepack is only available in newer versions of node and so the official migration guide does say to commit the binary for those who installed yarn from a different package manager(npm, homebrew, apt, etc)

[ragesoss]

Cool. I think we should go the route of building the instructions around the Corepack approach, rather than including the binary and maintaining compatibility with older node versions.

It would be good to add a section on upgrading yarn versions (with those simple instructions) to docs/upgrade_dependencies.md.

[TheTrio]

I've removed the yarn binary. Now Corepack is used to ensure that everyone is using the same version of yarn. The version is specified in package.json

[TheTrio]

As discussed, I've reverted this change. I found a way to use corepack on the CI after taking a look at the workflow of the corepack repository itself but its probably not worth the extra effort. When setup node supports corepack out of the box, this should be a lot more straightforward.

[ragesoss]

When I try this locally, I get errors while importing the dependencies. In particular (in addition to many warnings):

➤ YN0018: │ slick-carousel@https://github.com/cfoehrdes/slick.git#commit=a4d85536c42951933e1d887bcc013615e25b03e7: The remote archive doesn't match the expected checksum
➤ YN0018: │ list.js@https://github.com/WikiEducationFoundation/list.js.git#commit=3be71e3414d60e8a40b41a0ca8d582f2f40f9308: The remote archive doesn't match the expected checksum
➤ YN0000: └ Completed in 2s 6ms
➤ YN0000: Failed with errors in 2s 290ms