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

Add support for yarn berry v3 with PnP as install strategy #693

Closed
wdfinch opened this issue Feb 7, 2022 · 10 comments
Closed

Add support for yarn berry v3 with PnP as install strategy #693

wdfinch opened this issue Feb 7, 2022 · 10 comments

Comments

@wdfinch
Copy link

wdfinch commented Feb 7, 2022

Describe the feature you'd like to request

I would like to be able to use this tool with yarn berry v2/v3 as my package manager and Plug'n'Play as the install strategy.

Describe the solution you'd like

I would like the tool to support Plug'n'Play as the install strategy when using yarn berry.

Describe alternatives you've considered

Using another install strategy.

@thebanjomatic
Copy link
Contributor

thebanjomatic commented Mar 1, 2022

Can we get clarification on what support needs to be added here? I have tested locally by commenting out the util.IsNMLinker(cwd) check, and turbo run works fine with yarn 3 and the pnp linker (monorepo with around 50 packages). I would imagine turbo prune doesn't work, but if that's the case would you be open to a pull request that moves the isNMLinker check into the prune command specifically to enable yarn pnp for run?

It looks like maybe the bin script also needs work, but that can be fixed by changing:

const turboLibDir = path.dirname(require.resolve("turbo"));

to reference package.json since the turbo package doesn't have a "main" export and the above resolve fails:

const turboLibDir = path.dirname(require.resolve("turbo/package.json"));

kodiakhq bot pushed a commit that referenced this issue Mar 8, 2022
Regarding #693 (comment) I believe this at least partially addresses Issue: #693, but the scope of the issue is unclear.

More specifically this removes the general check for yarn pnp and moves it into the prune command instead as this is the part that likely has remaining issues with pnp since nothing else that I'm aware of needs to know about `node_modules`.

This PR builds off of #795, as otherwise you can't even run turbo to be able to hit the previous nodeLinker checks.

Let me know if you would like me to change things around so that it is more explicitly enabling for the run task as opposed to enabling for all but prune.
@jaredpalmer
Copy link
Contributor

This is now available in turbo run for turbo@1.2+

@wdfinch
Copy link
Author

wdfinch commented Apr 7, 2022

Great news! Thanks so much for working on this.

@geekuillaume
Copy link

It seems that only the node-module linker from yarn is supported (

return false, fmt.Errorf("only yarn nm-linker is supported")
). This issue is related to the PnP linker so it should be re-open

@arnoudius
Copy link

Would be really nice if nodeLinker: pnp could be supported.

@HosseinAgha
Copy link
Contributor

@jaredpalmer, As @thebanjomatic explained, looks like the yarn prune is not supported yet.
Should we follow this up in this issue or open another issue?

@Scherebart
Copy link

Scherebart commented Oct 12, 2022

Hello everyone!
Is this problem with support for yarn 3 pnp being resolved somewhere else?
Or is this subject dead for now?

Is this continued at #1066 ?

Thanks!

@nathanhammond
Copy link
Contributor

We currently have no plans to support Yarn 3 (Berry) in PNP mode. It was never supported (in spite of the earlier mention in this thread). The path to support for this is one of two options:

  1. Open a PR. We will accept this work if done by the community and maintain it in perpetuity.
  2. We're corporate-sponsored OSS. If your company needs this and is a Vercel Enterprise customer reach out through your account manager and we can start a discussion.

@Scherebart
Copy link

@nathanhammond
Thank you for clarifying this matter for me!

@alamothe
Copy link

Yarn PNP is de facto standard for monorepos. How is it possible that it's not supported?

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

9 participants