Support for Yarn Plug 'n Play

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 react/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

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

some news for PnP support?

None yet, unfortunately

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

@arcanis

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

@dalinarkholin

@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!

@dalinarkholin

@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 ?

@marudy

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

@thymikee

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!

No progress unfortunately

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?

Still waiting for this. Any news?

Any updates on this?

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.

@robhogan

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.

@szymonrybczak

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

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

@robhogan

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.

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.

This issue continues to kill me with regards to disk space. My 200mb app requires, somehow, 10gb of disk space to build and it sure would be a help if I could minimize the room my node_modules was taking up.

This issue continues to kill me with regards to disk space. My 200mb app requires, somehow, 10gb of disk space to build and it sure would be a help if I could minimize the room my node_modules was taking up.

I do not think that pnp would change much about that fact. Welcome to npm land :) Buy a large SSD, it will serve you well.

PnP would spare me the space that the largely duplicated node_modules folders of projects that share common technologies take up. Sure, I can run around like a maniac deleting and re-creating node_modules in a bunch of different projects, but that's extremely tedious and probably not helping the SSD's longevity.

As far as I understand it, with "zero installs" you commit all the sources for all the deps to the repository. So there is only a local cache, no global one. The feature is nice. yarn install takes maybe 10 seconds or so after a clone. But I heavily doubt that you will save disk space or disk writes by using yarn pnp.

Yarn can and does use global cache alongside local cache and Zero-install is an opt-in feature. Note the PnP and Zero-install aren't the same thing.

And importantly, This is not a place to discuss the Yarn's merits, please don't spam the people who subscribed to this issue.

Navigation Menu

Repository navigation

Support for Yarn Plug 'n Play #27

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for Yarn Plug 'n Play #27

Description

Activity

oshimayoan commented on Apr 15, 2019

ManAnRuck commented on Oct 7, 2019

thymikee commented on Oct 7, 2019

sebastian-nowak commented on Mar 16, 2020

dalinarkholin commented on May 8, 2020

natew commented on May 16, 2020

marudy commented on Dec 6, 2020

thymikee commented on Dec 6, 2020

jgornick commented on Apr 13, 2021

thymikee commented on Apr 14, 2021

ariccio commented on Jan 26, 2022

20 remaining items

wataruian commented on May 22, 2023

MohammadKurjieh commented on Aug 1, 2023

alamothe commented on Sep 21, 2023

robhogan commented on Sep 27, 2023

szymonrybczak commented on Oct 20, 2023

Nantris commented on Oct 21, 2023

levino commented on Oct 22, 2023

OneHoopyFrood commented on Jun 5, 2024

Nantris commented on Jun 5, 2024

Nantris commented on Nov 23, 2024

levino commented on Nov 25, 2024

Nantris commented on Nov 25, 2024

levino commented on Nov 26, 2024

BasixKOR commented on Nov 26, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions