Expo SDK 58 + React Native 0.88 + LiveKit 3.1.0 – npm ERESOLVE dependency conflict

Client SDKs
1

Hi LiveKit Community,

We’re trying to integrate LiveKit into an existing Expo React Native application, but we’re blocked by npm dependency resolution errors before reaching the native build stage.

Our environment:

  • Expo: 58.0.19

  • React Native: 0.88.0

  • React: 19.3.0

  • Node.js: 24.21.0

  • npm: 11.19.0 (also tested 10.9.4)

LiveKit packages:

  • @livekit/react-native@3.1.0

  • @livekit/react-native-webrtc@150.1.1

  • @livekit/react-native-expo-plugin@1.1.0

  • @config-plugins/react-native-webrtc@15.0.2

  • livekit-client@2.23.0

  • expo-dev-client@58.0.18

The problem:

Running npm install --package-lock-only --strict-peer-deps --ignore-scripts --no-audit --no-fund fails with ERESOLVE.

The primary conflict occurs through:

@livekit/react-native → @livekit/components-react → react-dom@19.3.1

react-dom@19.3.1 requires react@^19.3.1, while our application uses react@19.3.0.

In other isolated tests, npm also encountered conflicts involving Expo Router and react-server-dom-webpack.

We’ve reproduced the issue with npm 10 and npm 11, including when starting from our existing Expo SDK 58 lockfile.

Our questions:

  1. Has anyone successfully installed LiveKit React Native with Expo SDK 58, React Native 0.88, and React 19.3.0?

  2. If so, which exact package versions and dependency configuration worked?

  3. Is there a supported way to resolve the @livekit/components-react / react-dom peer conflict without using --force or --legacy-peer-deps?

  4. Is this a known dependency resolution issue with LiveKit React Native 3.1.0?

We’re looking for a reproducible, peer-compatible installation rather than a workaround that disables dependency validation.

Any guidance or a working example would be greatly appreciated.

Thank you!

2

This is outside my area of expertise. But maybe this will help?

Pin react-dom to exactly your react version using npm overrides — a first-class, reproducible, lockfile-deterministic mechanism (not a validation-disabling flag):

// package.json
{
  "overrides": {
    "react-dom": "19.3.0"   // match your react exactly
  }
}

Then npm install. This stops npm from floating react-dom to 19.3.1, the react@^19.3.1 demand disappears, and the install resolves cleanly under --strict-peer-deps.

If you’d rather be explicit, add it as a devDependency pinned to the same version instead:

"devDependencies": { "react-dom": "19.3.0" }

Either way, the key is that react-dom exactly equals react (not a range).

If that does not help, I will need to check in with our client team.