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...
For further actions, you may consider blocking this person and/or reporting abuse
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
You're welcome to publish without that as well, of course. 🙂
Oh thanks, I didn't know about that! I'll take a look 👍
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!
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.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?
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:
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.
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 🙂
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.
I think the problem is that the
extends
directives (and probablyparser
too) are supposed to userequire.resolve
in order to be fully portable. Cf what I did here for the Gatsby config:github.com/gatsbyjs/gatsby/pull/20...
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.
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 byjest-resolve
) still depends on 1.1.7. Onlybrowser-resolve
usesresolve@1.1.7
.Does this mean I can't update to Yarn 2?
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:Note that
$schema
is pointing tonode_modules
folder. With what URL should I change this line?Thanks.
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.
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?
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...
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?
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.
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 😂
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.
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.
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.
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.
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.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:
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.
Does anybody know how to uninstall yarn2???
Thanks in advance!
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
.npm install -g yarn
Are you sure???
I used uninstall and it removed it. Back to Yarn 1 =)
Congratulations! Great work.
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?
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?
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 runyarn unplug <name>
and the given package will be put into.yarn/unplugged
where you can edit it to your heart's content.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 makingYarn
better than it is right now.P.S:
I think there is a typo here:
This workflow is sill experimental
, should bestill
, right?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)?
I can't use it with a project I've been developing. It simply doesn't works. Will remain with the previous version.
Yes, it totally breaks things. Useless for now, unfortunately.
So from what I can tell this is the first release that Plug n' Play is the default. Is that right?
Yep.
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!
Looks great! I hope full support for react-native comes soon.
"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
How can I keep using Yarn 1? I accidentally installed Yarn 2 and it destroyed my application :(
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".
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?
Great post! Extra kudos for
lodash = 42
Congrats! That's a lot of work. Monorepo + workspaces workflows are what I'm most excited about.
Big Kuddos 🧶🎉
Are problems with global scope was resolved? Like:
yarn global add pm2
pm2 -v // pm2 - command not found
Impressive work! Thank you Maël 🙏
Awesome
Nice.
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
Great stuff; onward and upwards! :)
Hey, kindly, can you point me to an article that explains how I can create a yarn 2 plugin using TypeScript?
Please.
What about bundles that need to be rebuilt? Will they stay read-only during the command?
Yarn outdated being removed is annoying and basically a blocker.
Awesome release 😍
I love Yarn! Can't wait to play around with v2. Thank you for such great tool @arcanis <3