React Native

React Native "Unable to Resolve Module" After Installing Package

"Unable to resolve module" right after installing a package that should genuinely exist almost always means Metro's bundler cache is stale, or — for packages including native code — the JavaScript half installed correctly but the required native linking step hasn't actually happened yet.

The Problem

You install a package and import it, but Metro fails to bundle with:

Unable to resolve module some-package from App.js: some-package could not be found within the project
or in these directories:
  node_modules

None of these files exist:
  * node_modules/some-package/index(.native|.ios.js|...)

Checking node_modules directly confirms the package genuinely is there, which makes the "could not be found" message confusing.

Why It Happens

Several distinct situations produce this exact error message, and they need different fixes:

  • Metro's own cache still references the module resolution state from before the package was installed, and hasn't picked up the new package yet — this is by far the most common cause and the easiest to fix
  • The package was installed, but the app wasn't restarted (or Metro wasn't restarted) after installation, so the currently running bundler process genuinely doesn't know about it yet
  • For packages that include native code, the JavaScript package installed fine via npm/yarn, but the corresponding native module linking (iOS Pods, Android Gradle dependencies) never happened, which for many packages requires either autolinking to run correctly or an explicit native rebuild
  • A typo in the import statement, or a package that exports its main module from a non-standard entry point not matching what a plain import assumes

The Fix

First, and most commonly effective, clear Metro's cache and restart the bundler fresh:

npx react-native start --reset-cache

If you're using Expo:

npx expo start --clear

This resolves the majority of "unable to resolve module" errors that appear immediately after a fresh install, since it forces Metro to rebuild its module resolution map from scratch rather than relying on stale cached state.

If clearing cache alone doesn't help, fully stop the Metro process (not just reload the app) and restart it completely, since some cache states persist even through a reset flag depending on exactly what's stale:

# Kill any running Metro process, then:
rm -rf node_modules
npm install
npx react-native start --reset-cache

For packages that include native code, confirm the native side is actually linked. On iOS, this requires installing CocoaPods dependencies, which doesn't happen automatically just from an npm install:

cd ios
pod install
cd ..

For Android, native dependencies are usually autolinked automatically on the next build, but if you suspect this didn't happen correctly, a clean rebuild forces Gradle to re-resolve everything:

cd android
./gradlew clean
cd ..
npx react-native run-android

If you're using Expo Go (not a development build), confirm the package doesn't require native code that Expo Go itself doesn't include by default — some packages explicitly require a development build (expo prebuild + expo run:ios/run:android) rather than working inside the standard Expo Go app, and no amount of cache clearing resolves that specific mismatch.

Double-check the exact import statement against the package's actual documented usage, since some packages export their main functionality from a subpath rather than the package root:

// Sometimes the correct import is a specific subpath, not the package root
import { SomeComponent } from 'some-package/lib/components';

Still Not Working?

If none of the above resolves it, confirm the package actually installed into the correct node_modules directory being used by your project, which matters specifically in monorepo setups using workspaces — a package might install correctly at the monorepo root's node_modules while Metro is configured to resolve modules from a specific sub-package's own directory, or vice versa, producing exactly this "unable to resolve" error despite the package genuinely being present somewhere in the overall project:

find . -name "some-package" -path "*/node_modules/*" -not -path "*/node_modules/*/node_modules/*"

This searches for every location the package actually installed to across the project, which quickly reveals a monorepo resolution mismatch if one exists.

You might also like