DEV Community

Cover image for Reduce Expo Monorepo CI Build Time
Make-it.run
Make-it.run

Posted on Originally published at make-it.run

Reduce Expo Monorepo CI Build Time

Expo monorepo CI gets slow and flaky for the same reason: we treat all caches as one thing. Then builds run from the repo root, one app reuses another app’s Metro state, or native cache is blamed for a problem in dependency install. The result is a pipeline that looks fast until it starts failing in ways you cannot trust.

The fix is to give each layer a clear boundary. Run EAS commands from the app directory, not the monorepo root, so the build uses the right app config and the right scope. Restore the pnpm store before pnpm install, because that cache is about dependency content, not app behavior. Keep Metro cache separate for each app with an explicit cacheVersion, because shared transform cache can leak across apps in a monorepo. Then treat EAS cache as a separate native layer, with restore and save controls that you can turn on or off without disturbing pnpm or Metro.

The useful mental model is simple: every cache needs both a boundary and an owner. If you know what defines the cache and who is allowed to write it, build failures become easier to locate and cache speedups stay safe.

The cost is more explicit setup. You must version keys on purpose, and you cannot share cache state loosely across apps or untrusted CI jobs.


Read the full article on make-it.run →

Top comments (0)