-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback for Yarn 2 Setup #1
Comments
Thanks for taking the time to do this! You cleared up a ton! About the buggy-ness, I feel I may have been to harsh there as most of the bugs I encountered were with Yarn Classic. Things that I thought were bugs in Yarn2 turned out to just be configuration issues. I was able to get Yarn2 working properly by using node_modules instead of PnP. I'm a bit scared of PnP TBH - it seems too new at this time. I've updated the yarn2 branch and the readme. |
Ran into another problem today as I tried to take what I learned from doing this repo to an actual project. I believe it's a hoisting issue. Does Yarn2 have a way to nohoist specific modules as mentioned here: https://classic.yarnpkg.com/blog/2018/02/15/nohoist/ If not, I'm sure I can find another way around based on responses from: |
We haven't implemented To quote this response from our issue tracker, which was regarding
|
Thank you for this repo! Truly amazing 🙏 |
So... first I'm sorry that I haven't had the time to look into your issue yet. I've finally managed to take the time today and here's my feedback:
.yarn/releases
and.yarn/plugins
into your repository, otherwise Yarn will fail to spawn the binaries pointed byyarnPath
inside the.yarnrc.yml
. (Reference: https://yarnpkg.com/advanced/qa#which-files-should-be-gitignored)Thanks for pointing it out! We have a different website for Yarn 2 and we haven't yet updated the Classic website to mention Yarn 2 yet, and it looks like the installation page of the Classic website is prioritized by search engines because those links have existed for much longer.
Note that Yarn 2 automatically migrates your v1 lockfile, and it also a) removes lingering
node_modules
if you're using PnP b) invalidates yournode_modules
installation if you're missing thenode_modules/.yarn-integrity.yml
file (I don't remember exactly what it was called, it's something similar to that)That's how the per-project installs work. You install a v1 global binary (at least for now, we're still working this out) which spawns the v2 binary that you should commit into your repository so that everybody works on the same Yarn version.
At the top of the CLI documentation pages of these commands we have a banner saying that you need to install a plugin to use them:
In case you're wondering why not everything is included by default, it's because not everybody needs all the features. Not everybody uses monorepos to need
workspace-tools
and not everybody uses typescript to needplugin-typescript
.You're probably misinterpreting what this does.
plugin-typescript
automatically installs the corresponding@types/foo
package for eachfoo
package that you install that doesn't include it's own type definitions. Note that you can use thetypescript
package without needing any extra plugin,plugin-typescript
is just an optional convenience features. (That didn't exist in v1)That's because you're using the
--json
flag, which outputs everything as NDJSON (new-line delimited JSON, allows for easier streaming). If you want a human-readable output you shouldn't use the--json
flag, but I agree that the currentyarn workspaces list
output could look better.Regarding your original problem here, I can't seem to reproduce it. If you can, please provide a reproduction. If you're tired of this, you can switch to the
node-modules
plugin.Works for me after installing a few of the root dev dependencies (
typescript
,ts-node
,@types/node
) into the workspaces that need them. Note that:@types/node
to each workspace that needs it if you're going to run typescript inside a workspace (instead of from the root). This is because PnP is more strict and doesn't let you automatically inherit dependencies from the parent workspace.b) Under the
node-modules
plugin, you don't have to do anything else. Because of dependency hoisting,typescript
knows how to access@types/node
from the root.I'll look into that. Thanks for reporting!
If you want to continue to use PnP, I recommend you to use PnPify to help the
typescript
language server inside editors find your dependencies correctly. For more information: https://yarnpkg.com/advanced/editor-sdksPnP is harder to migrate to, but the
node-modules
plugin is a drop-in replacement for Yarn Classic that should (mostly) work out of the box.Other than the max listeners warning (which is also only a warning) I wouldn't consider anything else a bug. Most of this is documented inside the migration guide / PnP page / editor SDKs section. If something isn't, you can open an issue and we'll add it.
What important features are you missing? Mostly everything except a few npm-specific commands (
yarn team
,yarn owner
) and a few other very small things that we're already working on have already been ported over, and we've also added numerous other features that didn't exist in Yarn Classic (better workspace support, release workflow, constraints, plugins, more protocols, zero-installs, ...).Other than having to install
pnp-webpack-plugin
, it should mostly work out of the box. Note thatwebpack@5
now has native PnP support. Also note that the node-modules plugin doesn't require any extra stuff, it just works ™️ .The text was updated successfully, but these errors were encountered: