What Renovate may bump in an Expo app, and what it must never touch

Don't write the ignore list by hand

The fix itself is trivial. List the managed packages in Renovate's ignoreDeps and it leaves them alone.

The problem is maintaining that list. You would have to extract the subset of the 123 that your app actually installs, update it every time you add a dependency, and keep six apps in agreement. Three months later it will have drifted.

So I generate it from the expo package the app already resolves, which makes it structurally impossible for the SDK and the ignore list to disagree.

// scripts/gen-renovate-ignore.mjs
import { createRequire } from "node:module";
import { writeFileSync, readFileSync, existsSync } from "node:fs";
 
const require = createRequire(import.meta.url);
 
// Read from the expo the app actually resolves.
// Hardcoding a version here becomes a lie the moment you bump the SDK.
const managed = JSON.parse(
  readFileSync(require.resolve("expo/bundledNativeModules.json"), "utf8"),
);
 
const pkg = JSON.parse(readFileSync("./package.json", "utf8"));
const installed = new Set([
  ...Object.keys(pkg.dependencies ?? {}),
  ...Object.keys(pkg.devDependencies ?? {}),
]);
 
// expo itself is not listed in bundledNativeModules.json.
// Without this, Renovate will happily bump the SDK's major version.
const ignoreDeps = [
  ...new Set([
    ...Object.keys(managed).filter((n) => installed.has(n)),
    ...(installed.has("expo") ? ["expo"] : []),
  ]),
].sort();
 
const configPath = "./renovate.json";
const config = existsSync(configPath)
  ? JSON.parse(readFileSync(configPath, "utf8"))
  : {};
const before = config.ignoreDeps ?? [];
config.ignoreDeps = ignoreDeps;
writeFileSync(configPath, JSON.stringify(config, null, 2) + "\n");
 
const added = ignoreDeps.filter((n) => !before.includes(n));
const dropped = before.filter((n) => !ignoreDeps.includes(n));
 
console.log(`expo managed: ${Object.keys(managed).length} / ignored: ${ignoreDeps.length}`);
for (const n of added) console.log(`+ ${n}`);
for (const n of dropped) console.log(`- ${n}`);
 
// Exit non-zero on drift so this works directly as a CI gate.
process.exit(added.length + dropped.length > 0 ? 1 : 0);

Those three lines that add expo were not in my first version. I added them afterwards.

The trap: expo is absent from its own manifest

Running the first version against a test manifest produced this:

expo managed: 123 / installed & ignored: 12

Twelve. Comparing against the manifest by eye, expo itself was missing.

The reason is obvious once you see it. bundledNativeModules.json lists the surrounding packages whose versions the SDK governs. The SDK package is the thing doing the governing, not a thing being governed.

But expo is precisely the package you least want bumped. If it slides from 57 to 58 unnoticed, its agreement with all 123 surrounding packages collapses at once. Deriving the list from the manifest felt safe, and that feeling of safety was about to open the largest hole in it.

After adding the three lines:

expo managed: 123 / ignored: 13
+ expo
exit=1

Run it a second time:

expo managed: 123 / ignored: 13
exit=0

Zero exit when there is no drift. It is idempotent, so it can sit in CI without turning red on unrelated changes.

Bumping the SDK does not change the list

One more result went against my expectations.

To test it, I swapped the contents of node_modules/expo for SDK 56.0.18 and reran the same script. The managed set drops from 123 entries to 122.

expo managed: 122 / ignored: 13
exit=0

Still 13. No drift at all.

Obvious in hindsight: ignoreDeps is a set of package names, with no version ranges in it. Bumping the SDK moves 90 ranges, but names barely move. The only naming difference between 56 and 57 is expo-eas-client, which the test manifest does not install.

This changes where the check belongs. I had started sketching a step that regenerates the ignore list during each SDK upgrade. That step would almost always do nothing.

What this script actually catches is not SDK upgrades. It is forgetting to register a newly added dependency. You run npx expo install react-native-maps one week, and the next week Renovate proposes moving it from 1.27.2 to 1.29.0. This is what stops that.

So the gate goes on every PR that touches package.json, not on the upgrade workflow.

# .github/workflows/deps.yml
name: deps
on:
  pull_request:
    paths:
      - "package.json"
      - "package-lock.json"
      - "renovate.json"
 
jobs:
  renovate-ignore-sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      # We only need expo to resolve; no native build steps are involved.
      - run: npm ci --ignore-scripts
      - name: renovate.json ignoreDeps matches the installed SDK
        run: node scripts/gen-renovate-ignore.mjs
      - name: Show the drift when it fails
        if: failure()
        run: git --no-pager diff -- renovate.json

Planning the SDK migration itself is a separate problem, which I covered in keeping a Rork app's Expo SDK upgradable year after year.

Governing whatever is left

Once exclusion is automated, the Renovate config gets easier to write rather than harder. The dangerous set removes itself, so the remainder can take straightforward rules.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "timezone": "Asia/Tokyo",
  "schedule": ["after 9am and before 11am on monday"],
  "prConcurrentLimit": 3,
  "rangeStrategy": "bump",
  "ignoreDeps": [],
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["patch", "minor"],
      "groupName": "dev tooling",
      "automerge": true,
      "automergeType": "branch"
    },
    {
      "matchDepTypes": ["dependencies"],
      "matchUpdateTypes": ["patch"],
      "groupName": "runtime patches"
    },
    {
      "matchDepTypes": ["dependencies"],
      "matchUpdateTypes": ["minor"],
      "groupName": null
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true,
      "labels": ["deps:major", "needs-device-test"]
    }
  ]
}

ignoreDeps is left as an empty array on purpose. It marks the slot the script overwrites, and signals that it is not a field humans edit.

The two groupName: null entries are also deliberate. Runtime minor and major updates each get their own PR rather than being batched. Batching produces fewer PRs, but when behaviour shifts on a physical device you have no way to isolate which bump caused it. Anything that needs device verification does not get bundled is where I landed after running six apps in parallel.

Dev dependency patches and minors go the other way: grouped and auto-merged. If those break, CI goes red, and no human needs to read them.

How much is actually left

I ran this against a manifest close to what I use for a wallpaper app: 14 entries in dependencies and 2 in devDependencies, 16 in total.

The result was 13 of 16 under Expo's control.

Renovate was left free to manage exactly three: zustand, date-fns, and typescript.

I will admit that seeing that ratio made me stop and ask whether Renovate was worth running at all.

Two reasons it stayed.

First, those three sit outside Expo's compatibility contract. Nothing outside that contract has anyone looking after it. As it turns out, the packages that go stale most quietly were on that side all along.

Second, the Dependency Dashboard. The 13 excluded packages still appear there, listed as ignored. expo install --check tells you whether you have drifted; the dashboard tells you what you have deliberately chosen not to manage. Reading through that list twice a year has become the audit itself.

The order to roll this out

Adding this to an existing app in the wrong order buries you in pull requests on day one. This is the sequence I would recommend.

1. Fix the drift first. Run npx expo install --check --fix so every Expo-managed dependency matches the SDK. Skip this and you generate an ignore list around a drifted state, freezing that drift as the new baseline.
2. Generate the ignore list and commit it. Run node scripts/gen-renovate-ignore.mjs and commit the renovate.json it writes. The first run always exits 1, which simply means drift was found. That is expected.
3. Enable Renovate and watch the first batch. With prConcurrentLimit at 3, you get at most three PRs. Read all three before deciding whether to raise the limit.

Doing step 2 before step 1 locks the drift in place. Migrating six apps one at a time, I got this backwards on the very first one and had to unwind it. It is only an ordering detail, but it is one I actually got wrong.

Wrapping up

When you add automated dependency updates to an Expo-managed app, the starting point is generating the ignore list from the SDK.

Write it by hand and you will eventually miss something among the 41 packages that don't carry the expo name. In this measurement, the six that hurt most were sitting right there in those 41.

There is one command you can run against your own app right now.

npx expo install --check

Silence means you have not drifted yet. Any output is most likely drift that automation introduced. Building the ignore list can wait until after you have reverted it.

Since putting this in place, I can finally read Monday's pull requests without bracing myself. If it saves anyone running a similar setup some of that effort, I would be glad. Thank you for reading.