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!