Support for Yarn Plug 'n Play

[empyrical]

This is a meta issue to keep track of the things that need to be tweaked to give RN-CLI support for Yarn Plug 'n Play. This is probably non-exhaustive, more things might be found as others are tweaked.

• Global CLI: Support for finding react-native and react-native-local-cli when PnP is enabled (in progress: Add (very basic) Yarn Plug 'n Play support #26 )

• react-native bundle: Support for bundling dependencies with PnP. (Metro team is working on open sourcing its PnP support: Support for resolving Yarn Plug 'n Play modules facebook/metro#308)

• findPlugins: Plugin discovery code will need to be adapted to support PnP

• Xcode pbxproj files all have paths hardcoded in like this:

  path = "../node_modules/react-native/React/React.xcodeproj";

  There is, as far as I know, no way to have this path be dynamic. Ideally there would be some kind of way to have Xcode call a subprocess (like node resolve-dependency.js or something) and use it as the path's prefix, but I don't think there's a way. So I think a script might need to be made to refresh these paths and keep them up to date.

  This is also relevant for user libraries and react-native link for iOS dependencies

• Gradle scripts will need to be updated along with react-native link's Gradle output. Here's an example bit out output for react-native-webview:

  project(':react-native-webview').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-webview/android')

  The path to it is hardcoded to look in node_modules. I think a new helper function could be written, that would look something like:

  npm_dependency('react-native-webview', 'android')

  Where the first argument is the name of the node module, and the second is a pathname within the node_module. If PnP isn't present, then it will simply output an old-style path to node_modules. A similar function could be made for BUCK.

• Paths to node_modules/react-native are hardcoded in these files and will need to be updated. They could all use util/findReactNativePath, potentially.

  • local-cli/library/library.js
  • local-cli/eject/eject.js
  • local-cli/generator/templates.js
  • local-cli/link/__tests__/ios/getHeaderSearchPath.spec.js
  • local-cli/upgrade/upgrade.js
  • local-cli/util/findReactNativeScripts.js

[oshimayoan]

I saw #26 was closed. So how is this going?

[ManAnRuck]

some news for PnP support?

[thymikee]

None yet, unfortunately

[sebastian-nowak]

Any estimates on this, since yarn 2 is now stable and officially released? It defaults to PnP.

[dalinarkholin]

@arcanis @empyrical @thymikee I realize its been a couple years since this issue was created. I have been looking through the react-native code base and it is pretty clear to me that steps haven't really been taken by anyone to make this happen. I would like to start a conversation around supporting PNP for react-native, and possible solutions to make that happen. I think all the tasks @empyrical pointed out a couple years ago still apply.

There is so much tied to the existing node_module structure, I am not sure it makes sense to wholesale try and get expo itself to support pnp. Maybe step one is to provide a way for an ejected React native code base to use pnp more cleanly?

Note to anyone coming across this: I would eject before even trying to use pnp with react-native.

I have dug into this a bit and got things working with yarn berry and pnp enabled. You can see a working example here

Note: This is only working for IOS as of right now.

I ran into a lot of issues getting this setup and working but here are the things that I believe have to happen in order for it to work for IOS(this list is likely missing a few things as well as include things that don't actually need to happen, because my memory isn't perfect, and there is a lot going on here) If you pull down my repo, the readme should get things running. (you can see "foobar" getting pulled from a sibling workspace which is cool).

• Add package.json scripts to workspace for react-native related scripts (yarn pod:install, yarn pod:degenerate, etc). This is needed because of how yarn berry works.
• unplugs

"@react-native-community/cli": {
      "unplugged": true
    },
    "@react-native-community/cli-platform-ios": {
      "unplugged": true
    },
    "expo": {
      "unplugged": true
    },
    "expo-cli": {
      "unplugged": true
    },
    "jest-haste-map": {
      "unplugged": true
    },
    "react-native": {
      "unplugged": true
    },
    "react-native-unimodules": {
      "unplugged": true
    }

I believe you have to unplug at least the ones where pods are pulled from and are referenced from the PodFile. The PodFile doesn't seem to be able to reference files within a cached .zip.

• modify the paths in Podfile to point at the unplugs(this isn't great since those hash's can change after a yarn install at times. Script?
• Not sure autolinking works at all, so I manually added the one missing that I needed.
• Add a metro.config.js as seen here. This added a pnpResolver which it was included with Metro at one point, but seems to have been removed. The code here is pretty darn close to what was included before.

PNP Enabled issues.

---

• I got a chain of issues after adding pnp resolver to metro. First error was this guy . So I added a patch to metro see .patches/metro.patch in repo.
• Second was that crypto is not a npm module, so i created a passthrough workspace(see repo) to point at react-native-crypto. (learned about resolutions after the fact, probably could just do something like "crypto: react-native-crypto" Not sure that works.)
• Third issue was that process.version was undefined which crypto looks at from a submodule pbkdf2. Added a patch for it, but it did just get merged as well here: check if process.version is available browserify/pbkdf2#85 (comment) it might be a better solution here to actually include process? not sure how this works by default.
• If you checkout the .yarnrc.yaml you will see an insanely long list of packageExtensions. That it definitely not 100% accurate. Pretty sure some of those should be peerDependenicies, but they got me moving forward, and are likely needed in some form.

I ran into a million other issues, but I believe they were issues from trying to eject with pnp enabled initially.

Thoughts on any of this? If nothing comes of this, at at least there is an example of pnp working with react native on the webs.

To wrap up, IMO, yarn V2 is the future of JS/TS development. It was sort of crazy how many open and closed issues I ran into digging into this within the RN ecosystem...most of them dependency issues during buildtime, runtime, etc...all of which just sort of magically work, until it doesn't. As a community we need to start moving forward with Yarn V2, where we have a better grip of what is going on with our dependencies.

[natew]

@dalinarkholin Just wanted to say thank you. I wonder why this has been dead for so long, it's really odd to see two of the biggest FB projects totally out of sync for... going on 3 years.

Anyway, hope to see this move!

[marudy]

@dalinarkholin thanks for that. Wanted to try your example to verify that indeed I could build of course with yarn berry and also have a look at yarn install performance because this is the main reason for me wanting to move out from yarn v1.

After this was successful , I took some time to configure yarn berry into my project and see yarn install performance. The results speak for themselves:

yarn v1

• yarn install with no node_modules folder: 5 mins, 46 secs
  ✨ Done in 44.54s. ✨ Done in 301.41s.

yarn berry with PnP

• without cached install and without unplugged files, let's call this first time install: 1 min, 46secs
  ➤ YN0000: Done with warnings in 1m 46s

• without cached install files: 45 seconds
  ➤ YN0000: Done with warnings in 45s 587ms

• with zero installs and cache: 4 seconds
  ➤ YN0000: Done with warnings in 3s 808ms

I am working on a project with huge amount of packages and dependencies and every time I want to do a fresh install it takes a lot... Heck my CI has to eat up that time as well. I think it only makes sense move towards that direction. Also I believe there are lots of us willing to do dev tasks to complete this. I would be happy to help with parts where my knowledge and expertise makes sense if we can put this down to concrete tasks.

@arcanis @empyrical @thymikee what do you guys think? Shall we give berry a chance ?

[thymikee]

@marudy we're happy with accepting any help on how to make Berry work with React Native. Even in a form of the documentation :)

[jgornick]

Hi @thymikee and @marudy, it's been a few months since this was last commented on. I wanted to check-in to see if there has been any progress made with regards to React Native compatibility with PnP? This could be code changes, patches, documentation, workarounds, blog posts, anything 😄

We're looking to use PnP in a monorepo that also has a React Native application and wanted to check-in before we start digging.

Thanks!

[thymikee]

No progress unfortunately

[ariccio]

whimsically shakes fist

Darn it, I'm trying to switch to the fancy new yarn to make my monorepo all nice and clean, but the fact that this isn't just "batteries included" yet is a real pain point. Anybody know what's going on with support?

[PrimeDominus]

yarn berry please please please pretty please

[airtonix]

noone at facebook cares is the simple truth - we'd see progress on this if they did.

like... not even to do task planning on what needs to be done. nada... nothing.

[elmpp]

https://twitter.com/cpojer/status/1495511984330412034

…

On Tue, 10 May 2022 at 07:09, Zeno ***@***.***> wrote: noone at facebook cares is the simple truth - we'd see progress on this if they did. — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGTCZFFZULOPW7APPXF5CTVJHVPNANCNFSM4GD2AEUA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tj-mc]

Yarn Berry currently works fine so long as you use the nodeLinker: node-modules option in your .yarnrc.yml. This allows you to check in your .yarn/cache, then yarn creates the node_modules folder when you run yarn install. Because there's no network fetching, the install step will last a few seconds at most. This way you get most of the advantages of PnP until it is fully supported. Blog Post

[RobinBobin]

I didn't see .yarn/cache in git status -u, but then I saw I was just ignoring it by following the guide too strictly. Maybe it will help someone...

[alamothe]

@tj-mc I disagree brother. The node-modules is completely broken, especially if you work with TypeScript. We have dozens of shared workspaces in our monorepo and there is no way we would revert from PNP because of lack of support in RN.

[tj-mc]

@alamothe I haven't experienced anything odd using this in a Typescript repo in a single workspace.

[github-actions]

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

[michaelfaith]

Curious if this is going to be prioritized at some point?

[github-actions]

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

[fguitton]

Not stale 🎈

[tj-mc]

I can't see a motivation for Meta to build this, so it seems unlikely. Since the only incompatibility is related to the existence of node modules, Yarn Berry actually works fine with RN, you just need to use nodeLinker: node-modules as I explained in this post. Does that work in your use case? Also keep in mind Yarn 1 is not deprecated and is still actively worked on. Yarn 2 is not a direct upgrade but a totally new package manager, so you can continue to use 1 indefinitely.

[michaelfaith]

Also keep in mind Yarn 1 is not deprecated and is still actively worked on.

Not really though. Yes, they'd probably fix that CVSS 10 rated bug, but they're generally not fixing bugs or doing any enhancements that aren't related to yarn berry. There are a couple bug fixes that have impacted my group that they've flat out said they're not going to fix in yarn 1, as they've already fixed it in berry.

Yarn Berry actually works fine with RN, you just need to use nodeLinker: node-modules

I feel like the node-modules linker option is more of a stopgap to help people transition to PNP, not to be a final destination. This was especially useful as various libraries took longer to provide support. Ultimately the goal is to end up with PNP, hence this issue.

[arcanis]

I feel like the node-modules linker option is more of a stopgap to help people transition to PNP, not to be a final destination.

Just to clarify: the node_modules linker in modern releases of Yarn isn't a stopgap: it's a really good implementation (so good in fact that even pnpm relies on it as a dependency), significantly improved other the one in Yarn 1 (a couple of hoisting issues were fixed, new features were added), that we don't plan to sunset.

With that being said, it's true that a significant chunk of our users prefer to use PnP (a bit more than half, according to our data), so I agree it'd be nice to see this issue solved someday.

[michaelfaith]

Good to know. I just assumed that was implemented as a means to accommodate people who weren't able to fully move to PNP yet. Thanks for clarifying. (PNP is really nice though haha)

[levino]

Does anyone here actually work at Meta and can make any kind of reliable comment on this? I think "trying to predict what Meta might or might not do about this" is not really leading anywhere. I think it is reasonable to prevent this issue from getting closed as stale and hope that Meta eventually starts hiring again and then has some excess money to spend on dev time for RN. Until then probably nothing else can be done.

[wataruian]

Still waiting for this. Any news?

[MohammadKurjieh]

Any updates on this?

[robhogan]

Does anyone here actually work at Meta and can make any kind of reliable comment on this? I think "trying to predict what Meta might or might not do about this" is not really leading anywhere.

That's fair. We are rolling out support for symlink-based node_modules layouts, and with that support for most other modern package managers and package layouts, but we have no current plans to support PnP.

That would take non-trivial work in Metro's resolver and transformer, and there may be implications for native builds too (eg, native builds sometimes write build intermediates inside node_modules, which would be an especially bad idea in PnP).

The React DevX team isn't huge, we have to prioritise, and there's lots we're working on that we think will bring more benefit to RN devs - new debugger, improved dev tools, faster and more reliable bundling. We hope folks will be able to make use of improved package manager support in the latest versions, just not PnP for now.

[szymonrybczak]

As @robhogan said, we have no plans for supporting PnP, so I'm closing this issue. We know that package managers are important and we'll try to improve this space in future releases.

[Nantris]

@szymonrybczak can you clarify what exactly this might mean?

We know that package managers are important and we'll try to improve this space in future releases.

It's hard to parse the meaning when the preceding line says there's no plans to support PnP.

[levino]

In my experience bun is even better than yarn with zero installs. Fwiw this topic has become kinda obsolete for me.

[OneHoopyFrood]

As @robhogan said, we have no plans for supporting PnP, so I'm closing this issue. We know that package managers are important and we'll try to improve this space in future releases.

It would seem to me that the meta-issue should remain open as it sounds like there are tentative plans to support this in the future, if not concrete ones.

[Nantris]

I agree this should not be closed. The closing comment basically says, "We have no immediate plans to fix it, but someday we'll try to fix it because we know it's important."

I don't see why the issue should be closed with that in mind.