Welcome to the release notes for Yarn 3.1! We're quite excited by this release, as it brings various improvements that we've all been looking forwa...
For further actions, you may consider blocking this person and/or reporting abuse
I am super grateful that you named the option "pnpm" ❤️
I tried
nodeLinker: pnpm
instead ofnodeLinker: node-modules
, but I'm getting many errors likeCannot find module
But the modules are sub dependencies, so why should I require them to have them explicitly set in my own dependencies? I don't want to configure hundreds of dependencies when they get already declared as sub dependencies in the relevant packages
So what can I do to tell yarn that it should read the symlinks correctly?
Is there a hard links option that might work? Are you on windows?
We mostly use React Native and have used Yarn 1 from the start.
With React Native not supporting PnP, and it appears no one is working on it, is there any benefit to upgrading to 3.x (using
node_modules
)?I've found 2.x is way faster. I'd expect 3.x is even faster yet.
I hate that yarn needs to use a patched version of typescript. The logs and warnings are not very upfront. I'm waiting for typescript pnp pr to get merged.
The esm support is awesome. I remember rich harris tweeting something like "friends don't let friends use yarn 2". Once this is stable that will be really great, solve a nice batch of issues around pnp.
If you have developers on windows and have a shitty IT department, I've ran into an issue with yarn 2 where we were getting some security popup on windows, and it wasn't worth the effort to try and go through this crazy corporate approval process. I'm sure this is dependent on how you have installed node. Hopefully nvm-windows or Volta.sh would avoid such security prompts.
Actually I think we encountered the security prompts when using nvm-windows.
This is awesome!
I'm still using yarn 1 for my projects though
I would like to switch to the latest greatest, but not sure how to do the transition
Do you maybe have a tutorial that explains the process for these use-cases:
I'd like to know what are the new features one can simply use to improve install/build etc. time for the project
Hope I'm not asking too much.
It's just that usually yarn is set up only once in the beginning then it's a part of the app that you simply too scared to touch since it's working.
thanks!
This new workspace flags are 🔥
What's the best way to handle these special protocols during local development? I use
portal:
to get the same behaviour asnpm link
when I want to test an NPM package that I'm working on, but I don't want to commit my package.json file with theportal:../path/etc
stuff still inside of it.I could probably run a special ESLint task on pre-commit to prevent this, but maybe there is a better way?
At the moment no, we always use the local package.json as a local source of truth, there's no escape from that. For workspaces it's not a problem (since you can just edit them directly, you don't have to play with portals), but for 3rd-party vendors it'd be nice indeed.
Alright thanks. Just to clarify, I'm talking specifically about a scenario with Yarn + Lerna (mono-repo with NPM packages). Then I want to test the NPM package inside some other repository so I use
portal:..
(ornpm link
) to set that up. Having all workspaces inside the same repo as you describe would probably work, yes.Another issue is that Lerna cannot handle Yarn specific protocols (
workspace:*
), so any Lerna command (lerna version
/lerna publish
) will fail. This means we cannot use Yarn specific protocols in package.json.How to install yarn 3?
Just go into your directory and run
yarn set version stable
packageManager is great to know. Thanks for the info.