DEV Community

Introducing Yarn 2 ! 🧶🌟

Maël Nison on January 24, 2020

Hi everyone! After exactly 365 days of very intensive development, I'm extremely happy to unveil the first stable release of Yarn 2. In this post I...

Read full post

Ben Halpern • Jan 24 '20

This looks fabulous!

If you're interested in publishing officially as Yarn, you may consider setting up an org in your settings.

i.e.

Angular

This is where we write about all things Angular. It's meant to be a place for Angular community and people interested in Angular and the Angular ecosystem.

You're welcome to publish without that as well, of course. 🙂

Maël Nison • Jan 24 '20

Oh thanks, I didn't know about that! I'll take a look 👍

Zoltan Kochan • Jan 24 '20

For me, the monorepo release part is the most interesting. I will probably try it out in the pnpm monorepo. IMO, all the existing solutions are not scalable.

Zero installs are also cool but for me, installations are bearable with lockfiles.

Scripts that work on Windows are also very cool!

Jan Brummelte • Feb 1 '20 • Edited

I love the philosophy behind plug and play and all the other things of yarn 2. Thanks for the work you've put in.

You've said:
generally speaking as long as you use the latest versions of your tools (ESLint, Babel, TypeScript, Gatsby, etc), things should be fine.

That made me curious and I've tried using yarn 2. But it was not really true. ESLint shareable configs don't work. Adding all plugins as dependencies in a consuming package of a shared config does not really make sense.

And even with all dependencies up to date I've been running into problem after problem.

Please don't take this the wrong way, I love PNP and Zero-Installs. But things should be fine is just not true :-D The upgrade path requires a lot of manual steps and is still incomplete.

Maël Nison • Feb 1 '20

Which version of ESLint do you use? It's only since ESLint 6 that plugins are loaded relative to the configuration that declares them. Otherwise, if you have the name of the shared config, maybe we can check whether they do something custom?

Jan Brummelte • Feb 1 '20

I thought our biggest problem will be resolve aliases in the webpack config, from reading the migration guide. They should be replaced by using the "link:" notation. But we use dynamic aliases based on environment variables. "~custom" will be replaced depending on what customer we want to target. That seems to not be possible (dynamically).

But I can't even get to that point. I've already fixed a lot of problems, but now I'm stuck at:

webpack.config.babel.js:3
import path from "path";
       ^^^^

SyntaxError: Unexpected identifier

I've upgraded webpack (v4 not v5) and babel to the latest version and it still doesn't work.

Thanks for all the work you are putting in, I will continue debugging it tomorrow.

Maël Nison • Feb 1 '20

Note that this section of the migration guide isn't needed anymore (at least for Webpack), as we merged an improvement that doesn't make the PnP plugin incompatible with aliases anymore. The website still needs to be updated though 😅

github.com/arcanis/pnp-webpack-plu...

Note that we're relatively active on Discord, so feel free to pop in and join the talks - it's a good way to share feedback with our small community 🙂

Jan Brummelte • Feb 1 '20

Thanks for the fast reply, I'm using the latest ESLint version (6.8.0).

I'm trying to use my own eslint config (github.com/brummelte/eslint-config) with yarn 2.

Maël Nison • Feb 1 '20

I think the problem is that the extends directives (and probably parser too) are supposed to use require.resolve in order to be fully portable. Cf what I did here for the Gatsby config:

github.com/gatsbyjs/gatsby/pull/20...

Jan Brummelte • Feb 1 '20 • Edited

Thanks, I thought exactly the same and I've tried that. It still didn't work. But I will try again tomorrow to really make sure.

Manuele J Sarfatti • Jan 26 '20

Impressive, awesome news!

I encountered an issue using the migration guide, don't know if this is the right place to ask:

When I check for what version of resolve I have installed, I can see that while most packages use version 1.12 (so > 1.9), browser-resolve (which hasn't been updated in two years, and it's used by jest-resolve) still depends on 1.1.7. Only browser-resolve uses resolve@1.1.7.

Does this mean I can't update to Yarn 2?

gugadev • Feb 6 '20

I have a doubt with PnP. How handle compatibility with frameworks, like Angular. For example, a standard Angular project has a angular.json file with this content:

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "newProjectRoot": "projects",
 ...

Note that $schema is pointing to node_modules folder. With what URL should I change this line?

Thanks.

Maximilian Burszley • Jun 11 '20

Super late to this thread, but you can use the unplug command and point at that. There's a bug with Typescript 3.6.5 that breaks angular packages with pnp, however. They're working on adding support in v10 this summer, but that may be pushed back to v11.

jacob • Jan 30 '20

Very excited for zero-install!
I want to add a private registry that uses an auth token. I found the yarn config docs and wrote one for my project. It worked great! But I don't want to commit the auth token. Is it possible to use an environment variable instead?

The config docs mention using env vars for simple top level properties, but I think this falls into the not-simple case. One alternative is to require all devs to configure their own global yarnrc. But then there's the build server. All our other private config values are managed with environment variables. It's not straight-forward to add a yarnrc at build time. I think I could write the build to generate a yarnrc, retrieving the auth env var. Unfortunately I'm then maintaining many copies of the yarnrc. I doubt it changes often, but it will be easy for drift, and confusing when it does.

Any ideas?

ＶＩＴＡＬＩ⎝(•ω•)⎠!!JS • Jan 26 '20

A M A Z I N G !

I wonder if the "dependenciesMeta" will be able to serve as a "per-package-documentation".

I submitted an RFC about this sort of field a while ago:
github.com/yarnpkg/rfcs/pull/104/c...

Can Rau • Jan 27 '20

Yaaay so excited to try it out asap 🤩👏

Got a question regarding the local per project cache .yarn/cache are those files hard linked or copies? Asking because I'm curious if those files are duplicated on my laptops backup or not.
That's what happens with node_modules right? Those files are actual copies?

Hum this issue might be the answer, looks like it's been considered but got a little lost?

Maël Nison • Jan 28 '20 • Edited

It's complicated: "they are copies, but". The buts:

If you use zero-install, then yes those files are duplicated as each repository will have it. For this reason zero-install is better suited at monorepos than projects with dozens of repositories
If you don't use zero-install, we still cache the archives into a global "mirror" before cloning them using the native clone operation (when supported, mostly OSX). For this reason you only pay the size cost once when relevant.
If you don't use zero-install and don't use OSX, you can enable the global cache mode which will cause Yarn to use the global mirror as datastore (in which case you only pay the size cost once no matter what).

Note that all this is about the 2.x; the 1.x had worse characteristics.

Can Rau • Jan 28 '20

Interesting so I just stuff all repos into one then 😂 just kidding

Yea thanks for the summary I'll keep that in mind 🧠 Unfortunately I'm on macOS 😅

Are you still considering the hard link approach or is it too hard 🤔😅 haha sorry 😂

Sam Blowes • Feb 16 '21

One year on and still most developers arent using yarn v2?
Why?
In my opinion there are too many complexities and teething issues, which goes against one of Yarns very own philosophy "Developing Javascript projects should be easy" .

Source. github.com/yarnpkg/yarn/issues/6953

Does anyone here have positive experiences with yarn2? id love to hear them.

craigphicks-public • Mar 2 '22

I haven't use it yet - but cross platform scripting sounds exactly like something that could make developing easier.

However, my wish would be a step beyond that - I wish yarn would use use a package.js or package.ts file instead of package.json, and package.json would be generated just-in-time on the fly with a "yarn gen-pkg ..." command. That would really handy for dev vs rls modes, and for writing cross-platform scripts in nodejs.

Maël Nison • Feb 17 '21

Well, still most developers aren't using yarn v1 either :) such adoption is a slow and steady process, and we're fairly happy of our adoption rate. as for positive experiences, I suggest you come to our Discord, we have some regular users that will surely be happy to share their experience.

purpledrgn • Jan 31 '20

The last 3 points before the conclusion should be top 3, in fact they should just have their own section "How we stop node packages being a footgun". Security is not the "last concern."

Given the state of node package security of recent times even the crappiest in terms of features, fancyness and speed alternative to npm is much preferred if it actually solves some (if not all) high profile security concerns so everyone can sleep at night.

It's certainly a good step forward in other areas but I have to wonder what yarn does about "random dependency randomly building garbage" or why yarn doesn't just address all code that accesses "fs" and anything else into using a "safe" version (ie. error when reading anything outside, sending network packages, etc, unless explicitly granted). The "2" at the end feels more chilling then hype when major security concerns are not either addressed or their solutions clearly explained. If you do happen to do this, you've made a poor explanation of it.

Maël Nison • Jan 31 '20 • Edited

why yarn doesn't just address all code that accesses "fs" and anything else into using a "safe" version (ie. error when reading anything outside, sending network packages, etc, unless explicitly granted)

We want to do that, but it's impossible (or at the very least a completely different project) unless Node first implements proper builtin sandboxes. Even if we were preventing accesses to require('fs'), there is a bazillion ways to escape any "security" measure we could have.

purpledrgn • Feb 5 '20

Personally I would be more then happy with a "secure mode" that simply breaks any sort of "fancy" code people might have and requires explicit "whitelist" approval in package.json and very clear looking code for any sensitive such as imports, fs access, network access or global object access, etc.

Simple Checklist:

Does package access global object in any way? Blocked, no other checks necessary.
Does a import or require use anything that doesn't look like a regular dumb string? Blocked.
Every low-level network / filesystem / process-spawn package is replaced with an alias version that has some basic whitelist controls on it's sensitive methods.

There's no need to be flexible when implementing something like this. People need to adapt to the secure system until we have a better "flexible" secure system not the other way around. I would drop even high profile packages if it meant peace of mind.

I don't see any sort of node "sandboxing" making any difference in this regard and if the work in Dino is anything to go by, node level sandboxing is pretty stupid in practice with out user space assumtions.

Yuriy Markov • Feb 3 '20

Does anybody know how to uninstall yarn2???
Thanks in advance!

Maël Nison • Feb 3 '20

If you installed it from yarn policies set-version, just remove the line from your .yarnrc.yml file.

If you installed it globally, run npm install -g yarn.

Yuriy Markov • Feb 3 '20

npm install -g yarn
Are you sure???

1214586 • Feb 14 '20

I used uninstall and it removed it. Back to Yarn 1 =)

Jim Cummins • Jan 24 '20

Congratulations! Great work.

Zak Henry • Jan 24 '20

This is exciting! Any info about how performance compares? I perf was one of the many reasons to switch to yarn, I’m curious to know if if there continues to be improvements there?

Max Cerrina • Jan 26 '20

Does "readonly packages" mean that if I'm debugging, I can't hop into the source code of a given node_module and tinker with the code directly?

Maël Nison • Jan 26 '20

Readonly only as far as Node is concerned (ie you won't be able to writeFile directly into it). You can still use Emacs or Vim to open and edit the archives, and there is hope that VSCode will follow suite. And finally, you'll always be able to run yarn unplug <name> and the given package will be put into .yarn/unplugged where you can edit it to your heart's content.

sigfried • Jan 28 '20

What else can I add?, I'm not sure but I'm really excited to use the new Yarn. Thanks to all the people involved in the development process for making Yarn better than it is right now.

P.S:
I think there is a typo here:
This workflow is sill experimental, should be still, right?

Richard Brady • Feb 17 '20

Well done. Looks awesome. If it's a stable release, shouldn't it be versioned 2.0.0 (release) not 2.0.0-rc.27 (release candidate)?

1214586 • Feb 5 '20

I can't use it with a project I've been developing. It simply doesn't works. Will remain with the previous version.

Ruslan Shashkov • Feb 10 '20

Yes, it totally breaks things. Useless for now, unfortunately.

Gage • Jan 25 '20

So from what I can tell this is the first release that Plug n' Play is the default. Is that right?

Maël Nison • Jan 25 '20

Yep.

Gage • Jan 26 '20

So that means this is the first release that's like 70% faster with a hot cache. I'd say that's the best selling point right there!

Bruno Lemos • Jan 24 '20

Looks great! I hope full support for react-native comes soon.

devidpaul • Sep 9 '23

"Introducing Yarn 2" marks a significant leap in package management for developers. Yarn 2, the latest iteration of this popular JavaScript package manager, brings enhanced speed, improved project management, and better plug-and-play capabilities. Its innovations make the development process smoother and more efficient, catering to the evolving needs of the developer community.Gacha Nebula

1214586 • Feb 7 '20

How can I keep using Yarn 1? I accidentally installed Yarn 2 and it destroyed my application :(

Ruslan Shashkov • Feb 10 '20

You have to uninstall yarn and install its "legacy" version. In fact, its normal, not legacy and Yarn 2 must be some kind of "pre-alpha".

Johan Hernefeldt • Jan 26 '20 • Edited

Do you handle transitive dependencies with yarn 2?
Like yarn add pkgA@^1.0.0 which references pkgB@^1.0.0 and then there is an update to pkgB to version 1.0.1.
Will there be some way to upgrade pkgB from our project without having to totally replace pkgA?

Wilco Waaijer • Mar 24 '20

Great post! Extra kudos for lodash = 42

Ahmad Awais ⚡️ • Jan 25 '20

Congrats! That's a lot of work. Monorepo + workspaces workflows are what I'm most excited about.

Lilian Saget-Lethias • Jan 24 '20

Big Kuddos 🧶🎉

akopchinskiy • May 5 '20

Are problems with global scope was resolved? Like:
yarn global add pm2
pm2 -v // pm2 - command not found

Yann Bertrand • Jan 24 '20

Impressive work! Thank you Maël 🙏

Arthur • Feb 22 '21

Awesome

Jhoan Borges • May 7

Nice.

Rifqi Rosyidi • Mar 16 '21 • Edited

hi, just curious i just using yarn v2 but seems some of my dependencies in package.json seems not installing automatically when i run yarn install. how to solve this? in case anyone knows