As a powerful dependency management tool for JavaScript ecology, Yarn v2 was officially released on January 24 this year. In this article, I will introduce the following:

  • Why a V2 version
  • What’s new with V2
  • Yarn’s future plans

Note: You can see Getting Started if you want to know how to use v2 directly, and Migrations if you want to migrate from V1 to V2.

Why a V2 version

The existing code architecture cannot meet the new requirements

Yarn was created in early 2016. When it started, it borrowed a lot from NPM, and the architecture itself did not quite fit the vision of Yarn developers. Since then, Yarn has added many new features over the next few years, including Workspaces(2017), Plug’n’Play(2018), and Zip Loading (2019), as new requirements have been created. These new concepts did not exist when Yarn was first created. As a result, the Yarn architecture was not designed to allow for the addition of these new functions. As time goes by, Yarn code becomes increasingly difficult to maintain and extend. For this technical reason, Yarn needs a more modern code architecture to meet new requirements.

Developers are encouraged to contribute code

Yarn, as a community project, adheres to one of the concepts: We don’t want to work for you, we want to work with you. It can be seen that the developers of Yarn actually want more developers to participate in the development of the project, rather than only them to maintain it. To make it easier for developers to contribute code to the Yarn project, the following changes have been made to Yarn V2:

  • Moving from Flow to the more popular TypeScript as a development language allows developers to contribute code with a more familiar technology stack.
  • The Plugin-based Modular code architecture allows developers to add new functions to Yarn without understanding the core Yarn code. The core functions of Yarn are implemented by different built-in plug-ins, similar to Webpack’s design philosophy, so developers can easily understand how each function is implemented.

What’s new with V2

With that said, let’s take a look at the new features.

Output logs with higher readability

Although compared with other alternatives (such as NPM) Yarn output log is one of the more high readability, but it is all sorts of problems, such as when the output information much more special, developers are hard to find useful content in a lot of output, and the color of the output log does not help the user to quickly identify the important information, It may even interfere with the reading of the log. For these reasons, version V2 has some improvements to the output log, so let’s take a look at what it looks like:

The document

Yarn dlx

The YARN DLX has similar functions to the NPX. DLX is short for download and execute. The DLX command creates a temporary local environment to download the dependency. When the dependency is downloaded, it executes the executable binaries contained in the dependency in the current working directory (CWD). So these operations are one-off.

The yarn DLX command does not change the package. Json content of the current project, and it can only execute remote scripts, not local scripts (local scripts can be executed using Yarn Run), so it has higher security than NPX.

In V2, the Plug’n’Play function is enabled by default. After you run the yarn DLX command to execute a remote script, the dependency of the script is cached in the local environment. In this way, you do not need to download the dependency when the script is executed again.

Better workspaces support

One of the biggest changes in version V2 is that workspaces have been made first-class citizens to better support monorepo development. Workspaces are supported in version V2 in the following ways:

Yarn Add Adding interactive mode

If you are introducing a dependency in one workspace of your project, you may want to consider whether other workspaces also use the dependency, and avoid introducing incompatible versions. In v2, you can set the yarn add command to interactive mode by using the -i parameter. Yarn will check whether the dependency is used in other workspaces and will let you choose whether to reuse the dependency in other workspaces or to use a different version.

Update all workspaces at once for a dependent version

In version V2, the yarn up command is added. This command is similar to the yarn upgrade command. It is used to update a dependent version. Unlike YARN Upgrade, it can update the dependent version of all workspaces at the same time without switching to the update command in each workspace. This command also has an interactive mode -i to allow you to identify specific actions to be performed in different workspaces.

Automatically publish associated workspaces

Those of you who have worked on Monorepo will have encountered the problem that when a new version of a package (workspace) is released, it can be cumbersome to release other related packages. If you use Lerna in a project, when you release a new version of a package, you either have to release all the packages, or you have to manually manage the release of the other packages. It’s ok to manage the release of other packages yourself, but the human stuff can be negligent, and multi-person projects can be a pain. To solve this problem, Yarn V2 adopts a completely different solution from Lerna and other similar tools. It puts this part of the logic in a separate plug-in called Version. The Version plugin allows you to distribute a portion of the package versioning work to your code contributors, and it also provides a user-friendly interface that makes it easy to manage associated package releases:

Run the same command in multiple workspaces

It is common to run the same command in different workspaces of the same project. Yarn V2 provides a new Yarn workspaces foreach command that lets you run the same command in multiple workspaces. This command is supported by its built-in workspace-tools plug-in, such as the following command that runs the build command in all workspaces:

yarn workspaces foreach run build
Copy the code

Add constraints to all workspaces (contraints)

Sometimes you want all workspaces of the same project to follow certain rules, such as that all workspaces cannot use underscore as a dependency, or that all workspaces depend on a package version that is compatible with each other. The v2 version has a new concept called Constraints. Here, Constraints apply to the workspaces package.json within the project, just as ESLint does to JS files. It will give you an error message when the workspaces package.json breaks certain rules and will help you fix some of the errors.

Yarn constraint rules are written using Prolog syntax. To add constraints to your workspaces, you first need to introduce the constraints plugin:

yarn plugin import constraints
Copy the code

Then define a constraints. Pro file in the project’s root directory to hold the constraint rules, and finally define the desired constraint in this file. For example, the following constraint will prohibit all workspaces from using underscore as a dependency:

gen_enforced_dependency(WorkspaceCwd.'underscore', null, DependencyType) :-
  workspace_has_dependency(WorkspaceCwd.'underscore'._.DependencyType).
Copy the code

After the constraint rules are defined, run the yarn constraints check command to check whether the workspaces of the project meet the defined constraint rules. When an error occurs, run the yarn constraints fix command to automatically rectify the error.

Query workspaces dependencies as if they were a database

The yarn constraints query command is used to query the dependencies of workspaces in a project. For example, the following command outputs the lodash version used by each workspace:

$my-project: yarn constraints query "workspace_has_dependency(Cwd, 'lodash', Range, _)."➤ YN0000: Chrysene Cwd = 'packages/backend' └ Range = '4.17.0' ➤ YN0000: Chrysene Cwd = 'packages/frontend' ➤ YN0000: ├ Range = '4.17.0' ➤ YN0000: Done with warnings in 0.03sCopy the code

In my opinion, the above dependent query is very similar to the MySQL database query using SELECT syntax, which is a very powerful and useful feature.

Zero Installs (zero-installs)

Dependency zero installation is more of a concept than a feature. The idea is that after updating the code with Git, you do not need to run yarn install again to update the dependency of the local repository to improve development efficiency and avoid some problems. What it does is it lets you commit local dependencies to a remote Git repository, and you might be thinking, “Why not commit node_modules? This is stupid!” . Indeed, if you commit node_modules directly to a remote repository, each commit is a nightmare, because node_modules has a lot of files (tens of thousands of files are common), which makes it slow to upload and download code, and slow to review your code. To solve this problem, v2 will enable Plug’n’Play + zip loading by default. When this is enabled, your project will no longer have a node_modules folder, and all dependencies will be compressed into a single file in a specific location. The number of packages is not very large, so there is no problem with node_modules.

But why rely on zero installs? This is because it has the following benefits:

  • Better development experience
    • Every time you usegit pull.git checkout.git rebaseThese commands do not need to be used after you have updated your codeyarn installInstall dependencies to avoid problems such as code hanging if someone updates a dependency and you don’t.
    • Code review will make it clearer which dependencies have changed.
  • Faster, simpler, and more stable CI deployment
    • Because every time you deploy your code,yarn installThat’s a huge amount of time, and removing this step will speed up deployment dramatically.
    • – There will be no problems running locally but failing when publishing online.
    • You don’t need to configure the installation dependencies in the CI file.

If you want to see PNP + zip loading in action, you can look at the yarn V2 version and see that it is stored in the. Yarn /cache directory where all its dependencies are stored:

The new agreement

Two new protocols are added to Yarn V2: Patch and Portal. This is used to tell Yarn how dependencies defined in package.json files are resolved.

Patch agreement

In our daily development, sometimes we need to change a dependent source code to do some experimental things, and this time we can use the Patch protocol. Let’s see how to use it first:

{
  "dependencies": {
    "left-pad": "Patch: [email protected] #. / my - patch. The patch"}}Copy the code

Json defines how the dependency is resolved. You can see that the patch protocol is used to resolve the left-pad dependency. /my-patch.patch is a patch that we make to the left-pad library code, similar to the git diff file.

Portal agreement

The Portal protocol is similar to the original Link protocol. It is used to tell a dependency in the YARN project to point to a soft link (symlink) of the local file system. The function is similar to that of yarn link. Unlike link, Portal points to packages like package.json, and Yarn resolves the transitive dependencies file in the package. More specific differences between the Portal and Link protocols can be found in the official documentation.

Normalized Shell

The V2 version has improved compatibility with the Windows development environment. You might have encountered a problem before: the script command you define in package.json works on OSX, but it doesn’t work on Windows. The reason for this problem is that the script you define in package.json is eventually executed by creating a child process by Yarn, and the shell environment of the child process is different in Windows and OSX environments (e.g. file paths are written differently). To solve this problem, Yarn V2 comes with a simple interpreter, which is designed to be compatible with Windows and OSX shell environments and covers 90% of the common shell script writing methods. So normally the shell scripts you define will work in both Windows and OSX environments compatible with this parser:

{
  "scripts": {
    "redirect": "node ./something.js > hello.md"."no-cross-env": "NODE_ENV=prod webpack"}}Copy the code

Modular code architecture

As mentioned earlier, Yarn V2 has been converted to a modular architecture and supports user-defined plugins to enhance its functionality. User-defined plug-ins can obtain dependency tree information and other context information parsedby Yarn, so it is easy to implement libraries such as Lerna, Femoto, and patch-package.

Those of you who want to see how the Yarn plugin is implemented can take a look at the official typescript plugin implementation. This typescript plugin is very useful for typescript developers. It allows you to add @types/ packages for dependencies using the Yarn add command, so you can avoid a lot of manual work. More information about plug-ins can be found in this tutorial.

Other updates

In addition to the new properties mentioned above, version V2 also has the following updates:

  • Peer Dependencies can also be used in Yarn Link
  • The Lockfile format is changed to the standard YAML format
  • A package can only rely on dependencies declared in package.json. It is not allowed to require dependencies that are not declared
  • The configuration file is modeled
  • .

Those who want to see all of the new content in version V2 can see Mael Nison’s post on Introducing Yarn 2 or check out its change log directly.

Yarn’s future plans

  • The last version of V1, V1.22, has been released and the author will not add any new features to the v1 code. All new Yarn features will only be developed on the V2 code base.
  • The v1 repository will be taken fromyarnpkg/yarnMigration toyarnpkg/legacyThe repository will remain open for a period of time to fix bugs and will be achieved after a year or two. The v2 version of the code will not be migrated due to historical issuesyarnpkg/yarnAnd will remain for a long time to comeyarnpkg/berry.
  • – the official website of V1 will be moved to Legacy.yarnpkg.com, the content of yarnpkg.com is already the content of next.yarnpkg.com.
  • In the NPM repository,legacyThe tag points to the latest version V1 code,latestThe TAB will continue to point to the latest version of the code for V1 for a few weeks, and then to the code for V2.berryThe TAB will always point to the latest version of version V2.
  • In April, the Node 14 Docker image will come with v2 by default, so you can use v2 directly in the container.

reference

  • Yarn Berry Official document
  • Yarn 2 – Reinventing package management – Maël Nison aka @arcanis at @ReactEurope 2019
  • Introducing Yarn 2!

Personal Technology Trends

This article was first published on my personal blog

Welcome to pay attention to the public number attack leong learning and growth together