TL;DR When working with React Native and pnpm, just use node-linker=hoisted instead of trying to selectively hoist individual packages. It will save you hours of debugging mysterious codegen errors and Kotlin compilation issues. (If you're in a monorepo, you'll also need to update build.gradle paths to point to the root node_modules.) just use node-linker=hoisted build.gradle node_modules The Setup I'm working on a React Native 0.82 project in a pnpm monorepo. The structure looks like this: do-not-stop/
├── mobile/          # React Native app
├── frontend/        # Web app
├── backend/         # API server
├── packages/        # Shared packages
└── package.json     # Root workspace do-not-stop/
├── mobile/          # React Native app
├── frontend/        # Web app
├── backend/         # API server
├── packages/        # Shared packages
└── package.json     # Root workspace The Problem During an Android build, I encountered this error: Error: Cannot find module 'E:\git\do-not-stop\mobile\node_modules\@react-native\codegen\lib\cli\combine\combine-js-to-schema-cli.js' Error: Cannot find module 'E:\git\do-not-stop\mobile\node_modules\@react-native\codegen\lib\cli\combine\combine-js-to-schema-cli.js' The build was failing at the generateCodegenSchemaFromJavaScript task for @react-native-async-storage/async-storage. Classic React Native codegen issues. generateCodegenSchemaFromJavaScript @react-native-async-storage/async-storage The Initial "Solution" (That Didn't Work) Following the conventional wisdom, I added the missing packages to mobile/package.json: mobile/package.json {
  "dependencies": {
    "@react-native/codegen": "^0.82.1",
    "@react-native/gradle-plugin": "^0.82.1"
  }
} {
  "dependencies": {
    "@react-native/codegen": "^0.82.1",
    "@react-native/gradle-plugin": "^0.82.1"
  }
} This seemed logical - the build needs these packages, so let's add them as dependencies. Right? Wrong. Wrong. The Rabbit Hole Deepens After adding these dependencies, I started getting Kotlin compilation errors: Unresolved reference 'NativeRNWalletConnectModuleSpec'
'getName' overrides nothing
'getTypedExportedConstants' overrides nothing Unresolved reference 'NativeRNWalletConnectModuleSpec'
'getName' overrides nothing
'getTypedExportedConstants' overrides nothing The errors were coming from @walletconnect/react-native-compat, which was trying to use codegen-generated classes that weren't being found. @walletconnect/react-native-compat Attempting Selective Hoisting I tried selective hoisting - first with a simple hoistPattern in package.json (which created even more issues with inconsistent paths and module resolution), then with a more sophisticated public-hoist-pattern configuration in .npmrc that others claim works. Here's the more comprehensive example: hoistPattern package.json public-hoist-pattern .npmrc # .npmrc

# so gradle / metro can see my local package
hoist-workspace-packages=true
public-hoist-pattern[]=@myOrg/sharedPackage

# so gradle and metro can see various cli tools and settings
public-hoist-pattern[]=@react-native-community/*
public-hoist-pattern[]=react-native
public-hoist-pattern[]=@react-native/codegen
public-hoist-pattern[]=@react-native/gradle-plugin
public-hoist-pattern[]=@babel/runtime

# i happen to be using this, and it has a complex native build step that didn't work without this hoist.
# might be true for other packages that have native build steps
public-hoist-pattern[]=react-native-gesture-handler # .npmrc

# so gradle / metro can see my local package
hoist-workspace-packages=true
public-hoist-pattern[]=@myOrg/sharedPackage

# so gradle and metro can see various cli tools and settings
public-hoist-pattern[]=@react-native-community/*
public-hoist-pattern[]=react-native
public-hoist-pattern[]=@react-native/codegen
public-hoist-pattern[]=@react-native/gradle-plugin
public-hoist-pattern[]=@babel/runtime

# i happen to be using this, and it has a complex native build step that didn't work without this hoist.
# might be true for other packages that have native build steps
public-hoist-pattern[]=react-native-gesture-handler This configuration uses public-hoist-pattern (instead of hoistPattern in package.json) and includes workspace packages, a broader set of React Native packages, and packages with native build steps. But it still didn't work for me. This is exactly the problem with selective hoisting - even configurations that work for others can fail in your specific setup because: public-hoist-pattern hoistPattern package.json But it still didn't work for me. React Native versions differ
Dependency trees vary based on your packages
Build tools evolve and change their expectations
Native modules have different requirements React Native versions differ Dependency trees vary based on your packages Build tools evolve and change their expectations Native modules have different requirements If a configuration this comprehensive still fails, it's a clear sign that selective hoisting is fragile and outdated. The fact that it works for some but not others is precisely why full hoisting is the safer choice. The Real Solution After hours of debugging, I finally gave up on selective hoisting and went nuclear: Added .npmrc at the root: Added .npmrc node-linker=hoisted node-linker=hoisted The hoisted linker ensures all packages are in a single node_modules directory, which React Native's build system expects. node_modules For pnpm monorepos specifically, updated mobile/android/app/build.gradle to point to the root node_modules: For pnpm monorepos specifically, updated mobile/android/app/build.gradle node_modules react {
    // Point to root node_modules since we're using hoisted linking in a monorepo
    reactNativeDir = file("../../../node_modules/react-native")
    codegenDir = file("../../../node_modules/@react-native/codegen")
    cliFile = file("../../../node_modules/react-native/cli.js")
    
    autolinkLibrariesWithApp()
} react {
    // Point to root node_modules since we're using hoisted linking in a monorepo
    reactNativeDir = file("../../../node_modules/react-native")
    codegenDir = file("../../../node_modules/@react-native/codegen")
    cliFile = file("../../../node_modules/react-native/cli.js")
    
    autolinkLibrariesWithApp()
} The paths go up three levels because: mobile/android/app/build.gradle → mobile/android/ → mobile/ → root mobile/android/app/build.gradle → mobile/android/ → mobile/ → root mobile/android/app/build.gradle mobile/android/ mobile/ Note: If you're using pnpm with a standalone React Native project (not a monorepo), you only need the .npmrc change. The build.gradle modifications are only necessary when your React Native app is nested in a monorepo structure. Note: .npmrc build.gradle The Lesson Selective hoisting in React Native projects using pnpm is a false optimization. You might think: "Couldn't I just track down all the React Native-related packages that need hoisting?" Technically, yes - you could spend hours finding @react-native/codegen, @react-native/gradle-plugin, @react-native/metro-config, @react-native/babel-preset, and all the other RN packages. But React Native's dependency structure changes frequently between versions. What works today might break tomorrow when you upgrade React Native or one of its tooling packages. You'd be playing whack-a-mole with your hoist patterns every time you update. false optimization @react-native/codegen @react-native/gradle-plugin @react-native/metro-config @react-native/babel-preset React Native's build system expects a certain structure. When you have Gradle looking for codegen, Metro bundler resolving modules, native code trying to import generated classes, and multiple tools working together, you need consistency, not clever path resolution. Hoisting everything gives you that consistency, and it's future-proof. consistency That said, if you really want to save disk space and are willing to maintain a selective hoisting configuration with pnpm's hoistPattern or public-hoist-pattern and symlinking strategies, it's technically possible. But this requires deep knowledge of React Native's dependency graph, ongoing maintenance as packages update, and potential debugging time when things break. That said hoistPattern public-hoist-pattern If you've successfully set up selective hoisting for React Native with pnpm and want to help others, please share your configuration in the comments! Include your .npmrc settings, package.json hoist patterns, and any build.gradle modifications you made. If you've successfully set up selective hoisting for React Native with pnpm and want to help others, please share your configuration in the comments! .npmrc package.json build.gradle Conclusion Next time you're setting up a React Native project with pnpm, just hoist everything from the start. Your builds will be reliable, and your debugging time will be spent on actual features, not dependency resolution. This article is part of the do-not-stop project - a full-stack Web3 playground with React Native mobile support. This article is part of the do-not-stop project - a full-stack Web3 playground with React Native mobile support. do-not-stop Have you had similar experiences with React Native and pnpm? Share your horror stories (and solutions) in the comments! Have you had similar experiences with React Native and pnpm? Share your horror stories (and solutions) in the comments!

The Real Fix for React Native + pnpm: Hoist Everything

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How Multiple Valtio Instances Broke My React Native App

Using ChatGPT Like a Junior Dev: Productive, But Needs Checking

I Reverse-engineered How 23 'AI-first' Companies Actually Build Their Products

Voice Assistants: Past, Present, Future

About Ten Open Source Technologies That Are Changing the World

10 Most Sought-After Programming Languages You Should Learn In 2021

How Multiple Valtio Instances Broke My React Native App

Using ChatGPT Like a Junior Dev: Productive, But Needs Checking

I Reverse-engineered How 23 'AI-first' Companies Actually Build Their Products

Voice Assistants: Past, Present, Future

About Ten Open Source Technologies That Are Changing the World

10 Most Sought-After Programming Languages You Should Learn In 2021

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps