Get best of the week

Yarn 2 - with Prolog and plug-ins

Yarn - the package manager for the node - released the second version . And, it seems, the guys seriously set out to change the status quo in the node ecosystem, or even package managers in general. Delete all the pictures about gigabyte Nurse node_modules, remove yarn installfrom scripts CI, we start another great JavaScript-confusion. In short:

  • Plug'n'Play mode became default, and node_modules became secondary, through the plugin.
  • We made a plugin and workflow for monorep - maybe lerna will not be needed.
  • They built in their mini-shell so that the scripts of the package can be run without these of your cross-envs in Windows.
  • Added a prolog to check the rules between workspaces.
  • npx again washed down their.
If you do not want to update all your projects, just run yarn policies set-version ^1(see legacy.yarnpkg.com/en/docs/cli/policies ) in the repositories that should remain on Yarn 1 and commit the result. Then Yarn will use the local Yarn 1 binaries instead of the global ones, so everyone on the team will use the same version!


In general, two directions of development can be traced: a) maximum reproducibility of the environment and b) movement towards a platform for package management.

Regarding the first point, yarn always drove - in fact, this was the reason why it once appeared, immediately pushing npm (I recall, then running npm install could give different results, because the lock file in the node world is the merit of yarn) . Although I personally switched to it because of the furious line in the npm logs .

But now they decided, so to speak, to push to the limit. When you add a package, it (and all its dependencies), in the form of a zip archive, is added to the cache, in the .yarn folder in the package folder (like .git). Instead of node_modules, a .pnp.js file is created, which processes module imports. There are two important consequences:

  1. You can add this cache directly to git - and then after the checkout you will immediately have the current version of the application with all the dependencies.
  2. Yarn link works much better - now peer dependencies are also processed correctly

As for the platform, the guys switched to the plugin architecture (that is, yarn primarily as an API, and then later as the CLI) and even announced that they want to get rid of the node itself, making yarn a generic solution for building your own package managers .

It sounds interesting, ambitious, and slightly arrogant. Let's see if they can cope or stall already at the PnP-first stage.

In any case, I will try to transfer our project to yarn 2, if it works out - it will be nice. How are you?

UPD: About the prologue in the title is not a joke, it will be possible to write the rules for checking workspaces on it, next.yarnpkg.com/features/constraints

Next - an extract from the official announcement .

The most important


Output in the console redesigned for better readability
CLI Commands ( yarn add...) Now consider vorkspeysy
You can get rid of yarn installwithin its repository
of less hazardous alternative npx: yarn dlx, to run a one-time things
Run command on all vorkspeysah with yarn workspaces foreach
Mankipatching packets through the patch log:
Links to local packages through the portal protocol:
A new workflow to release workspaces normally
Declarative check and workspace fixes (PROLOG INCLUDED)

And also ...


Packages are built only if without this it is completely
impossible. Package builds can be turned on / off.
Scripts are run in the universal shell.
Peer dependencies work even through yarn link.
Lockfile has become regular YAML.
All code is now on TypeScript.
Plug-in support.

Breaking changes


Settings have become uniform.
Packages must comply with their boundaries.
Bundle dependencies are no longer supported.
Packages are stored in read-only archives.

Detailed changelog is here , update instructions are here .

Will it be difficult to move to Yarn 2?


Thanks to our beta testers and overall ecosystem support, we have eased a lot of the pain associated with such a massive upgrade. The relocation guide will tell in more detail, but in general, while you use the latest versions of tools (ESLint, Babel, TypeScript, Gatsby, etc.), everything should be normal.

But there is one significant cant: Flow and React-Native cannot be used with Plug'n'Play (PnP) right now . We are looking for ways to work with their teams to make it work. Right now, you can stay on Yarn 1 or use the node_modules plugin , which provides backward compatibility to facilitate the transition (it is still in operation, there may be bugs). More here .

What will happen to the old version?


Yarn 1.22 will be released next week. After this, the 1.x branch will officially enter live mode - that is, there will be no releases other than vulnerability fixes. New features will be made exclusively in Yarn 2. In practice, this means:

  • The old repository (yarnpkg / yarn) will leave for yarnpkg / legacy to reflect its surviving status. It will be open for some time, but most likely we will archive it in a year or two.
  • The new repository will not be renamed to yarnpkg / yarn, as this will break many old links. For the foreseeable future, he will remain at yarnpkg / berry .
  • The old site will go to legacy.yarnpkg.com, the new site (now next.yarnpkg.com) will move to the main domain yarnpkg.com
  • The yarn package on npm will be updated like this:

    • The berry tag will always show on the latest 2.x release
    • legacy 1.x
    • latest legacy , berry. , Yarn 2.
  • - Node Yarn 2 Node 14, 2020 . yarnPath Yarn 2 .
  • We are switching to fully automatic GitHub Actions and some batch repositories (in particular Homebrew, Chocolatey, etc.) are not yet screwed. As a result, they will receive a Yarn 2 update later than the rest. We recommend using yarn set version (or yarn policies set-version on Yarn 1).

We expect that most of these changes will be completed by February 1, 2020.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles