Yarn is certainly no stranger to front-end developers. At present, most of them use the version of Yarn 1.x. In fact, the positioning of Yarn 1.x is often a bit awkward. It still borrows a lot from npm in design, even in the eyes of most developers, they just replaced package-lock.json with yarn.lock( yarn workspaces is quite different), although it claims to have an advantage in speed, the disadvantage of npm, Yarn 1.x will inevitably exist.

Therefore, it promotes the emergence of Yarn 2, while keeping the usage and functions of 1.x as much as possible, it also proposes and implements / reconstructs a lot of new functions. At present, 1.x is no longer updated, and 1.x documents have been transferred to https://classic.yarnpkg.com/. This article will not describe in detail what new features Yarn 2 has introduced, but only learn about Yarn 2 from the perspective of installation, and current development mode, which can be seen in Changelog or Features.

Install Yarn 2

We often encounter different versions of npm when maintaining multiple projects, so we often need to install multiple Node.js on the same machine, so nvm and nvm-windows appear, but as developers, we should still remember to switch versions between different projects. Yarn 2 believes that it should be a dependency of the project, and even the version should be locked (of course, it can be upgraded), so Yarn 2 will maintain itself into the project and still need to complete the installation with yarn 1:

Npm install-g yarn # Global installation yarn 1
Yarn-version # A

Although it may seem strange, it is understandable that it is impossible for such a popular tool to be completely covered without considering compatibility and migration difficulty, and the emergence of Yarn 2 also ensures the normal use of the original Yarn 1.

Upgrade to Yarn 2 in the project

As mentioned earlier, Yarn 2 treats itself as a common dependency of the project, so upgrading Yarn 2 is also project-specific:

Cd / path/to/project
# If the version obtained from line A above is 1.22+.
Yarn set version berry # B1

# If the version obtained from line A above is lower than 1.22
Yarn policies set-version berry # B2

After executing line B1 or B2, a .yarn directory and a .yarnrc.yml configuration file are added to the root directory of the project:

• .yarn Directory: stores the specific execution files of Yarn 2, the dependencies installed by Yarn 2, etc.
• .yarnrc.yml Configuration file: this project aims at the specific configuration files of Yarn 2, which is similar to the functions of .npmrc and .yarnrc. Note here that Yarn 2 will no longer read the configurations in .npmrc and .yarnrc, and the file extension must also be yml, .yarnrc that cannot take effect.

# Initial structure of .yarn directory
.yarn
Thank you for releases
Thank you for your yarn-berry.js

# Initial structure of .yarnrc.yml
YarnPath: ".yarn / releases/yarn-berry.js"

Both .yarn and .yarnrc.yml should be submitted to the warehouse.

Upgrade Yarn 2 version

Because Yarn 2 is still in rapid iteration, upgrading the version of Yarn 2 is also a routine operation to fix problems or to experience new features. Fortunately, upgrading the Yarn 2 version is also easy and provides a number of ways:

# Upgrade to the latest release-Volkswagen
Yarn set version latest

# Upgrade version from master branch-try it fresh
Yarn set version from sources

# Upgrade version from other branches-specific requirements need to be addressed
Yarn set version from sources-branch 1211

The above is updated directly from the Yarn 2 warehouse to your project. After the upgrade is completed, you generally need to update the dependency through yarn or yarn install.

After installing / updating Yarn 2 according to the above steps, you should be able to run Yarn 2 normally under the current project. You can confirm whether it is the current version 2.x by yarn-- version.

Managing dependencies with Yarn 2

Some common ways of using Yarn 2 are no different from Yarn 1, such as:

# Installation dependency
Yarn
Yarn install

# Add dependency
Yarn add [package] [--dev |-- peer]

# Delete dependency
Yarn remove [package]

Of course, there are also some new / replacement commands: for example, yarn up is used to update dependencies (yarn upgrade in Yarn 1.x), yarn dlx is used to temporarily execute dependencies (similar to npx), see the CLI documentation for details.

Here we focus on dependent installation, which may be dumbfounded if we do it in the project now:

• More . pnp Js file;
• Many files in the .yarn directory;
• node_ The modules directory has been emptied;
• The project may not be able to run.

Meaning of new files in .pnp.js and .yarn directories

It has to be mentioned that Yarn 2 uses pnp to install dependencies by default. The most important difference from traditional node_modules management dependencies is that all dependencies exist as zip packages, and are stored in the .yarn / cache directory by default. Managing dependencies as a zip package has a fatal problem: our code can't recognize it, let alone find the corresponding dependency file, so Yarn 2 generates a .pnp.js file for us to solve this problem. As for the advantages of using this approach, here is a brief list. If you are interested, you can take a look at the official explanation.

Yarn 2 believes that the locking that the project depends on should not only be achieved by yarn.lock, but should also be committed to the repository, so the .yarn directory should be submitted to the repository. This is not feasible in the traditional node_modules mode, not only because of the number of changes generated after the update, but also because the number and volume of files in a slightly larger project node_moduels are easy to reach the point that Git cannot handle. Because Yarn 2 uses the zip package to manage dependencies, it greatly reduces the number and size of files, so that the project dependency can be versioned, and then the dependency locking can be realized perfectly.

In the current engineering collaborative development, after the collaborator pulls the replacement code, the first step is to install the dependency, but Yarn 2 has changed this situation. Now that the project dependency has been submitted to the warehouse, the collaborator does not even need to perform the dependency installation step after pulling the replacement code, because the dependency is already there, which is the zero installation zero-install proposed by Yarn 2. This also solves the problems such as the server network restriction can not download dependence, the new branch upgrade depends on the old branch can not operate properly and so on.

Solutions that the project can't run

Is it possible that our project will be completely normal with .pnp.js? Unfortunately, it's not that simple: many tools don't implement the Plug'n'Play specification yet, so it's possible that your project still doesn't work right now, does that mean we can't use Yarn 2? Of course not, Yarn 2 provides two ways to install dependencies: pnp (default) and node-modules (not node_modules), and configuration:

# .yarnrc.yml
YarnPath: ".yarn / releases/yarn-berry.js"

# If the project doesn't work, you can try to add the following configuration first:
NodeLinker: "pnp"
PnpMode: "loose"

# If you still can't run, you can use the following configuration in full accordance with the previous dependency.
NodeLinker: "node-modules"

If nodeLinker is "pnp" (default), pnpMode defaults to "strict", in which case all dependencies used must be explicitly declared in package.json, that is, if your module declares webpack as a dependency, webpack declares acorn as a dependency, in "strict" mode your module cannot directly introduce acron, otherwise an error will be reported. The "loose" mode is allowed, but not recommended.

Setting nodeLinker to "node-modules" is no different from installing dependencies in Yarn 1 and npm, all dependencies still exist in the node_moduels directory, and in these cases no .pnp.js file is generated, because there is no need to resolve dependencies from the zip package.

There are some well-known front-end tools to support, specific can see the support list, I believe there will be more and more support over time.

Yarn 2 configuration

Yarn 2 can be configured through yarn config CLI or by editing the .yarnrc.yml file directly. Some configurations are quite different from those of Yarn 1.x. All configurations can be found in the official configuration documentation. Here is an example of the configuration of a private domain:

# Use yarn config
Yarn config set-json npmScopes'{"lwz": {"npmRegistryServer": "http://npm.lwz.com"}}'
Yarn config set-- json unsafeHttpWhitelist'["* .lwz.com", "lwz.com"]'

Use -- json to allow complex configurations, otherwise you can only configure configuration items of string, number, and boolean types

When the private domain name is not https, you need to add unsafeHttpWhitelist configuration to add the private domain name. You can use wildcards.

Corresponding to. yarnrc.yml：

# .yarnrc.yml
NpmScopes:
  Lwz:
    NpmRegistryServer: "http://npm.lwz.com"

UnsafeHttpWhitelist:
  - "*.lwz.com"
  - "lwz.com"

Complex configurations are recommended to be edited directly in .yarnrc.yml. Using yarn config set to set an existing configuration is an overriding process, so if you want to retain the previous configuration, you also need to bring the previous configuration with you.

Summary

This article only explains how to use Yarn 2 from the user's point of view, and does not explain its new features, advantages and other aspects in depth, which will be explained in the future. If you want to learn more, you can consult the official documentation.