Skip to content
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

Open
paul-soporan opened this issue Aug 29, 2020 · 4 comments
Open

Feedback for Yarn 2 Setup #1

paul-soporan opened this issue Aug 29, 2020 · 4 comments

Comments

@paul-soporan
Copy link

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:

  • You should commit .yarn/releases and .yarn/plugins into your repository, otherwise Yarn will fail to spawn the binaries pointed by yarnPath inside the .yarnrc.yml. (Reference: https://yarnpkg.com/advanced/qa#which-files-should-be-gitignored)
  • It's not immediately obvious there is a V2. At least by googling "yarn for windows"

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.

  • Delete all existing build files and yarn specific files: ./.dist/ & ./node_modules/ & ./yarn.lock

Note that Yarn 2 automatically migrates your v1 lockfile, and it also a) removes lingering node_modules if you're using PnP b) invalidates your node_modules installation if you're missing the node_modules/.yarn-integrity.yml file (I don't remember exactly what it was called, it's something similar to that)

  • Ignore the fact that it says v1.22.4 or similar

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.

  • Install some plugins yarnpkg.com/api/modules/plugin_typescript.html
    Many of the documented commands come from these, and IMO it's easy to miss that these are addons

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:

image

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 need plugin-typescript.

yarn plugin import typescript # I guess it's not batteries included like V1

You're probably misinterpreting what this does. plugin-typescript automatically installs the corresponding @types/foo package for each foo package that you install that doesn't include it's own type definitions. Note that you can use the typescript package without needing any extra plugin, plugin-typescript is just an optional convenience features. (That didn't exist in v1)

  • Check workspace setup * Note: It's no longer easily readable for humans

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 current yarn workspaces list output could look better.

  • (BROKEN) Run script command defined in package.json for a specific workspace
    There's no longer an easy built in way to do this.
    Be sure to install plugin workspace-tools

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:

  1. Scripts in workspaces don't have access anymore to the binaries of the parent workspaces.
  2. a) Under PnP (which you're currently using), you have to add @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.
  • ➤ YN0000: MaxListenersExceededWarning: Possible EventEmitter memory leak detected.

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-sdks

  • Disqualified because it's painful to use [...]
    [...] Classic way simplier and pretty much worked out of the box.

PnP 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.

  • buggy

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.

  • lacking in features compared to yarn classic

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, ...).

  • and more difficult to integrate with webpack v4.

Other than having to install pnp-webpack-plugin, it should mostly work out of the box. Note that webpack@5 now has native PnP support. Also note that the node-modules plugin doesn't require any extra stuff, it just works ™️ .

@DerekZiemba
Copy link
Owner

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.

@DerekZiemba
Copy link
Owner

DerekZiemba commented Sep 2, 2020

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:
electron/forge#869
electron/packager#774

@paul-soporan
Copy link
Author

We haven't implemented nohoist in Yarn 2 because we haven't seen any strong use case for it - all of them are just workarounds because projects don't resolve node_modules in Node-compliant ways.

To quote this response from our issue tracker, which was regarding react-native:

Perhaps it would be the responsibility of the node-modules plugin to support nohoist? Or there are other workarounds before React Native supports PNP?

To explain a bit our position, nohoist was literally only implemented in order to make RN's life easier with workspaces, and it caused a bunch of implementation problems with various other parts of the architecture. The fix would technically be on RN's side but, same as PnP, the leadership doesn't really make it a priority.

So here we are, three years later ... our choices are either to support legacy settings for the benefit of a project with much more resources than us, or assume that they'll eventually fix that on their side ... 😕

@alamothe
Copy link

Thank you for this repo! Truly amazing 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants