🔥[🐛] Pod install fails when using monorepo structure in bun

[TabithaLarkin]

Issue

I have a project set up with bun and a monorepo structure, with the RN expo app in a sub-directory. When working with bun workspaces the package install linker uses an isolated install strategy. Modifying the bunfig.toml settings to include hoisted linker settings solves the issue, but at the cost of no longer being able to use isolated installs.

[install]
linker = "hoisted"

When expo prebuild is run the following failure is seen during the pod install phase.

⚠️  Something went wrong running `pod install` in the `ios` directory.
Command `pod install` failed.
└─ Cause: Invalid `Podfile` file: 
[!] Invalid `RNFBMessaging.podspec` file: No such file or directory @ rb_sysopen - ../app/package.json.

 #  from [monorepo root]/node_modules/.bun/@react-native-firebase+messaging@23.8.8/node_modules/@react-native-firebase/messaging/RNFBMessaging.podspec:3
 #  -------------------------------------------
 #  package = JSON.parse(File.read(File.join(__dir__, 'package.json')))
 >  appPackage = JSON.parse(File.read(File.join('..', 'app', 'package.json')))
 #  
 #  -------------------------------------------
.

 #  from [monorepo root]/apps/[subdirectory]/ios/Podfile:49
 #  -------------------------------------------
 #  # @generated end react-native-maps
 >    config = use_native_modules!(config_command)
 #  
 #  -------------------------------------------

I believe this is due to the linking present between the node_modules folder in the app directory and the root directory. The appPackage file can't be located due to the relative path used to resolve the location of the file.

---

Project Files

Javascript

Click To Expand

package.json:

{
  "name": "expoapp",
  "version": "1.0.0",
  "main": "index.ts",
  "scripts": {
    "dev": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "lint": "eslint --ext js,ts,tsx .",
    "test": "jest",
    "prebuild": "expo prebuild --clean"
  },
  "dependencies": {
    "@react-native-async-storage/async-storage": "2.2.0",
    "@react-native-firebase/app": "^23.8.8",
    "@react-native-firebase/messaging": "^23.8.8",
    "expo": "~55.0.8",
    "expo-build-properties": "~55.0.10",
    "expo-constants": "~55.0.9",
    "expo-dev-client": "~55.0.18",
    "expo-linking": "~55.0.8",
    "expo-notifications": "~55.0.14",
    "expo-router": "~55.0.7",
    "expo-status-bar": "~55.0.4",
    "react": "19.2.4",
    "react-dom": "19.2.0",
    "react-native": "0.83.2",
    "react-native-safe-area-context": "~5.6.2"
  },
  "devDependencies": {
    "@types/react": "~19.2.2",
    "typescript": "~5.9.2"
  },
  "private": true
}

firebase.json for react-native-firebase v6:

# N/A

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

 I would include this, but I'm using expo and bun, and the result of that command is somewhat broken with this combo.

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  • 23.8.8
• Firebase module(s) you're using that has the issue:
  • e.g. Instance ID
• Are you using TypeScript?
  • Y & 5.9.2

[mikehardy]

Hi there, the @react-native-firebase/app package has an entry in it's package.json file that sets the firebase-ios-sdk (and firebase-android-sdk...) version numbers in order to pull the correct pods down, and all the other packages expect to be able to inspect that file to fix their version number as it currently stands.

is the isolated installs config per package in your monorepo, or if you had to change to hoisted for the react-native app, would that imply the entire monorepo would have to be hoisted? Curious for the impact for monorepo+bun users

either way, I'm not really sure what the alternative here is without propagating the version number for the transitive native dependencies into all the packages here

[TabithaLarkin]

is the isolated installs config per package in your monorepo, or if you had to change to hoisted for the react-native app, would that imply the entire monorepo would have to be hoisted? Curious for the impact for monorepo+bun users

It has to be changed to hoisted for the entire monorepo unfortunately

[TabithaLarkin]

@mikehardy
Sorry for the ping, but I did notice in the expo documentation there is a section regarding relative file paths in build scripts that may be of use.