I counted how many versions expo install starts recommending after one patch bump

Only Expo's own modules were moving

This is the part that ran against my expectation. I assumed that bumping the patch would pull the third-party recommendations forward as well.

Every one of the 30 entries that moved between 57.0.17 and 57.0.19 was an expo-* or @expo/* package. expo-updates went ~57.0.18 → ~57.0.20, expo-widgets went ~57.0.13 → ~57.0.16, and so on.

Not a single third-party entry moved. react-native stayed at 0.86.3, react at 19.2.3 — and note that neither carries a tilde or a caret. They are exact pins.

Which means the recommended versions for Sentry or AsyncStorage will not advance no matter how many expo patches you apply. They move when the next major SDK lands, and not before. "Bump expo and everything else falls into line" only holds for Expo's own modules.

That asymmetry changes how I think about dependency updates. As an indie developer shipping on my own, my default has been to upgrade whatever can be upgraded. Then, on the Android side of one of my wallpaper apps, I bumped an image library on its own — the library was fine, but its combination with the build toolchain crashed launch on older devices only. What broke was not the library. It was the combination. The 22 pinned entries are exactly where Expo has absorbed that combination risk on your behalf.

Measuring how far npm install drifts

So how far does the muscle-memory npm install actually take you? Here are the ledger values next to the npm latest, both measured on 2026-09-02.

Sentry, AsyncStorage, and WebView each jump a major. A major bump in a native module almost always asks something of your build config or your init code. npm install brings that request in silently.

This matters most when an AI writes the setup steps for you. Ask for "a fast list with FlashList" and the generated instructions will usually include npm install @shopify/flash-list. Whether it translates that to npx expo install depends on the generation. The person receiving the output has to know the difference.

One check to drop into a freshly generated project

Running npx expo install --check would cover this. In practice, the week I forget to run it is the week three dependencies get added. I would rather have CI fail, so I added a script that compares package.json against the installed ledger.

// scripts/check-bundled.mjs
// Compare package.json dependencies against the ledger inside the installed expo.
// Anything absent from the ledger (zustand and friends) is outside Expo's
// verified set, so we stay quiet about it.
import { readFileSync } from "node:fs";
import { createRequire } from "node:module";
 
const require = createRequire(import.meta.url);
const ledger = require("expo/bundledNativeModules.json");
const pkg = JSON.parse(readFileSync("package.json", "utf8"));
const deps = { ...pkg.dependencies, ...pkg.devDependencies };
 
const strip = (r) => r.replace(/^[\^~]/, "");
const rows = [];
 
for (const [name, range] of Object.entries(deps)) {
  const want = ledger[name];
  if (!want) continue;                       // not verified by Expo, skip
  if (range === want) continue;              // exact match
  const pinned = !/^[\^~]/.test(want);       // is the ledger value an exact pin?
  const same = strip(range) === strip(want);
  if (pinned && !same) rows.push([name, range, want, "ledger pins this exactly"]);
  else if (!pinned && !same) rows.push([name, range, want, "outside the ledger range"]);
}
 
if (rows.length === 0) {
  console.log("no dependencies conflict with the ledger");
} else {
  console.log(`dependencies conflicting with the ledger: ${rows.length}`);
  for (const [n, got, want, why] of rows) {
    console.log(`  ${n}\n    package.json: ${got}\n    ledger:       ${want}  (${why})`);
  }
  process.exitCode = 1;
}

Run against a package.json where expo, expo-image, and react-native follow the ledger but FlashList and Sentry were installed at latest:

$ node scripts/check-bundled.mjs
dependencies conflicting with the ledger: 2
  @shopify/flash-list
    package.json: ^2.3.2
    ledger:       2.0.2  (ledger pins this exactly)
  @sentry/react-native
    package.json: ^8.24.0
    ledger:       ~7.11.0  (outside the ledger range)

Some drift is deliberate, so failing unconditionally would make the check unusable. I pair it with an allow list that records the reason.

// Dependencies we knowingly keep outside the ledger, with the reason attached
const ALLOW = {
  "@sentry/react-native": "need v8 Session Replay; temporary until the SDK 58 ledger catches up",
};
 
// One line inside the loop is enough
if (ALLOW[name]) continue;

Having a place to write the reason is what makes this survivable six months later. The problem is rarely the drift itself — it is that nobody wrote down why the drift was accepted.

What to do with a dependency that drifted

Once the check goes red, the decision splits three ways. Which one you pick determines how much work follows.

Bring it back to the ledger

The lightest option. Re-run npx expo install <package> and it drops to the ledger version. I take this route by default: if I cannot articulate why latest is required, matching the ledger makes the next SDK upgrade cheaper.

One gotcha. When this means a downgrade, node_modules and the lockfile can disagree and resolution fails outright. Running npm install once, or regenerating the lockfile before retrying, is the reliable workaround.

Keep it outside on purpose

Sometimes the ledger version simply lacks a feature you need. Packages that ship features quickly — Sentry is the usual example — can outpace the ledger by enough that waiting is not an option.

In that case, write the reason into the allow list above and add a rough expiry ("until the next major SDK"). Being outside the ledger is not the problem. Having no record of why is.

Defer the decision

If you cannot decide today, keep the check from failing while still surfacing the drift: treat only the exact pins as errors.

// Fail CI on exact-pin drift; leave range drift as a warning
const fatal = rows.filter(([, , want]) => !/^[\^~]/.test(want));
if (fatal.length > 0) process.exitCode = 1;

Exact pins like react-native or Skia are the layer where drift tends to surface as a production build problem rather than a lint complaint. Failing on those alone keeps the check alive while undecided dependencies sit in the warning column. Failing on everything is how a check gets commented out, so this is the split I recommend.

When local and CI disagree

Because the ledger ships inside expo, a different expo patch on CI produces a different expo install --check result. There are essentially two ways to end up there.

1. package.json says "expo": "~57.0.x" and the lockfile is not shared (or CI runs npm install and rewrites it)
2. CI restores a cached node_modules where expo is still on the previous patch

Both present as symptoms that look like a corrupted lockfile. What is actually out of sync is the ledger version. One line separates the two.

# Run this locally and on CI; the numbers should match
node -p "require('expo/package.json').version"

If those differ, align expo before touching anything else. Since making this the first question, I have stopped losing time to the lockfile. The wider set of checks I run after generation is in the acceptance checks I still run after the build turns green.

The ledger tells you how heavy an SDK upgrade will be

There is a second use for this. The ledger diff doubles as a preview of the next SDK upgrade.

When expo@58 lands, I plan to extract both ledgers and run drift.mjs before reading anything else. How many of the 22 exact pins moved tells you how deeply the upgrade reaches into native code. If only Expo's own modules shifted, it is a light upgrade. If Sentry or AsyncStorage jumped a major, block out time for init code and build settings.

The number arrives before the release notes do, which is why I like this order: know how much changed before reading what changed.

If your project runs expo prebuild, an SDK upgrade also wipes hand-edited native files. That one is covered separately in finding the native edits prebuild will erase.

What to do next

Open any Expo project you have and run this:

node -p "Object.keys(require('expo/bundledNativeModules.json')).length"

If it prints 123, those 123 packages are the combination Expo verified. Count how many of your dependencies appear in that set, and how many of those match the ledger version. The ones added by npm install will stand out immediately.

I treated expo install and npm install as interchangeable until three minors of FlashList taught me otherwise. The difference is not the command name. It is whether a ledger is being consulted at all.