Yarn 2 features

For details, see Introducing Yarn 2! . I am concerned about workspace and PnP.

workspace

Workspace: Yarn has a plugin that provides a new command, Yarn workspaces foreach.

However, as early as Yarn@1, it is possible to run monorepo’s subpackage command by executing commands such as yarn workspaces run script. However, notice this but, if the script is not present in the package, an error will be reported (I laughed).

Yarn@2 added this command, which looks similar, but at least no more errors, so that I don’t need to write empty scripts or use lerna to help execute scripts in Monorepor.

PnP

This paper mainly focuses on PnP. What is PnP?

There’s a well-known graph:

The wheel guys decided they had to save the universe. Using PnP would make dependencies flat, avoid duplicate files as much as possible, and make dependency lookup more efficient.

The native node method of finding dependencies is to recursively traverse the node_modules folder to the parent directory. Although the existing package management versions have been promoted to make dependencies as flat as possible, there are still nested directories when the package dependency versions do not match.

PnP, on the other hand, records the location of the dependent quasi – group disk, which can reduce the disk read and write when searching for dependencies. At the same time, all dependencies can be completely flattened.

RC

Has been interested in the PnP features of YARN for some time (tried using YARN before — PnP too). When it officially entered the RC stage, I decided to try it again, so in 2020.02, I started a “bold” trial.

ROUND 1 (install)

Documentation is always beautiful:

yarn set version berry
yarn install
Copy the code

The first problem occurs because some packages are in the corporate domain and cannot fetch because Yarn 2 no longer reads the NPM configuration.

However, npmRegistryServer is immediately discovered as you need to configure unsafeHttpWhitelist to access Registry if it uses an HTTP address. Of course, this step is not required if Registry supports HTTPS.

ROUND 2 (pnpify)

Pnpify the corresponding toolchain according to the requirements of the document. This step is not a big hole, but a little tedious, see this document for detailed steps:

yarn dlx @yarnpkg/pnpify --sdk vscode
# 1. Open ts file in vscode
# 2. Select the typescript version by clicking on the lower right corner or using CTRL + Shift + P
# 3. Use the PNP version of typescript for Workspace
Copy the code

At this point, you’re ready to code, but the first stop comes — you can’t view the type definition file.

Although type hints are available via the pnpify toolchain, vscode does not provide preview capabilities because the dependency is now essentially a zip package rather than a folder.

ROUND 3 (Compatible mode)

PnP may have gone too far, but it provides the nodeLinker: Node-Modules configuration to give us a black hole.

At this point, there is a second blocking point — NPM scripts cannot be executed. For example, jest, ESLint, etc., are unexecutable. The reason is because the original NPM execution used node_modules/. Bin as the environment variable, but now Yarn@2, the executable is nowhere to be found… Scripts must be executed using YARN, resulting in many NPM scripts (such as NPM run clean && NPM run build) having to be modified.

conclusion

There are several deficiencies of resistance:

  • Unable to view type definition file
  • Some NPM scripts cannot be executed
  • Dependency resolution is very slow on cold startup (this reason was not thoroughly investigated)

For the above reasons, Yarn@2 has caused a huge impact on the usage habits and cognition of most developers, which I think is not conducive to promotion. At that time, I (Wallcrack) do not recommend using it.

2.3.3

Time after half a year, eat too full, I once again ready to “destroy the sky and the ground” charge.

ROUND 1 (Compatible mode)

First, I tried the compatibility mode of nodeLinker: Node-Modules in an existing project. Good, I don’t know which version, but at least in this compatibility mode, the familiar node_modules/.bin is back, allowing developers to gradually use Yarn@2.

Of course, this round is not so smooth, first of all, the Link stage will be very slow.

Yarn 2 The installation steps are divided into three steps: Resolution, Fetch, and Link.

It was incredibly slow, especially at Electron, because there was no feedback from the interface, I couldn’t tell if the process was stuck or not, so I had to turn off Built to complete the installation (again, a new configuration item) :

// package.json
{
  "dependenciesMeta": {
    "electron": {
      "built": false}}}Copy the code

ROUND 2: Install

With compatibility mode as a guarantee, I felt emboldened to try PnP. However, as a result, not only was Link slow, but it didn’t even succeed, looking at the logs, it looked like the error was all related to the Fsevents repository.

Here N minutes of Google time are omitted

The conclusion is that using the latest version of Yarn can be broken:

yarn set version from sources
Copy the code

Try to access XXX, but it isn’t declared in its dependencies.

This is because although many packages are actually used in combination, in theory, each package should not be aware of the existence of other packages, and each package’s dependencies should be explicitly declared in dependencies. If an error is reported because some package dependency descriptions are not strict, you can fix the following configuration (note that, as the name suggests, this configuration only works in PnP mode) :

pnpMode: loose
Copy the code

After that, the dependency installation is relatively smooth. Of course, since there is no bin directory in PnP mode, all scripts need to be executed using YARN XX.

ROUND 3 (pnpify)

This step was the smoothest, and I was also pleased to discover the vscode plug-in ZipFS, which solved the pain point of not being able to view type definition files in vscode. Sure enough, The Wheels don’t leave users alone.

There is still some impact on the old habits, but overall there is no breaking point in the current development experience.

ROUND 4 (Library)

Yarn 2 can be used in normal service projects. What about in tripartite library development? (Mainly involving NPM publish and other operations).

Sure enough, the disaster is coming, Yarn 2 house! However! No! Confess! General! Prepublish hook, etc. This causes many existing workflows to crash, such as this script:

"prepublishOnly": "npm run clean && npm run build && npm test"
Copy the code

Yarn NPM publish ignores all hooks, which is not expected. However, if I continue to publish with NPM, I will crash because there is no bin directory.

Dilemma, left and right to think, although not completely no opportunity, but have to write a compromise issued command:

"pub": "yarn clean && yarn build && yarn test && yarn npm publish --ignore-scripts"
Copy the code

Is it easy for me?

conclusion

Compared to the February RC release, this fixes the pain point of not being able to view type definition files, but currently, scripts are too intrusive to be completely compatible with the old conventions. Also, not only fsevents, but many libraries (many of the storybookJS libraries seem to have errors) require various Google fixes and are currently incompatibable.

Therefore, at this point in time, Yarn 2 can be enabled in some service projects to save hard disk space. The saved space can save some precious film and television materials. But all in all, for now, I still don’t recommend it.

Other thoughts

Zero Install

The idea behind yarn@2 is to host both dependencies and executables in the repository so that project development can get started quickly. But I’ve been a little torn inside, feeling like it’s like hosting node_modules on Git… Therefore, in the current project I have used enableGlobalCache: True to externalize dependencies to the project.

But things like Yarn Releases (executables) and YARN plugins (workspaces), I’m not too keen on hosting either. However, we can accept that this part of the file is not updated frequently, and that sometimes you do need to use the YARN executable of a certain development version to complete the dependency installation of the project. Using Git hosting can avoid repeated efforts by the collaborators.

Saving grace?

Q: With all these disasters, is there anything fragrant about yarn@2?

A: Nothing special. In addition to loading X — oh, no, to prove you’re full — you save disk space.