fix(install): warn when dependencies come from a bun other than .bun-version

Closed
SA
13d ago
+9-0

Where the cause is: the root cause is outside apps/mobile. It is the version of bun that installs the dependencies on a cloud box. This PR changes root install config (scripts/postinstall.sh). fingerprint.config.js and eas.json stay unchanged: they are already correct.

Problem

A cloud sandbox computed a different development-simulator fingerprint than EAS. eas-dev.sh found no matching build, started a ~15 min build, and that build failed at "Configure expo-updates". The workaround was MOBILE_EAS_BUILD_ID.

Cause

The "Configure expo-updates" log of the failed builds f8ebea6a and fbc879f6 (commit 035965bc, 2026-10-17) gives the fingerprint diff. Only three autolinked sources differ, and only in the bun store suffix:

sourcesandboxEAS
@expo/dom-webview@57.0.1/ios+74e171d88a660d73+6dc057f194158d3d
@expo/log-box@57.0.4+74e171d88a660d73+6dc057f194158d3d
expo-symbols@57.0.3/ios+945b7335f0d7483f+5d9a54ca60cce305

The expoAutolinkingConfig:ios podspec dirs that contain these paths differ too.

+74e171d… is bun 1.3.14's name for these entries. Build ccee2940 (2026-10-08) shows the same pair the other way round: EAS was still on its default bun 1.3.14 then, and the submitting machine was on 1.4.2. #8313 pinned EAS to 1.4.2. On 10-17 the sandbox was on 1.3.14:

  • .bun-version was 1.3.14 until e1347c78 (2026-10-03).
  • packages/sandbox/src/image.ts installs bun only in the image (npm install -g bun@${BUN_VERSION}). The nightly bundle updates do not install bun, so a box made from an older image keeps 1.3.14.

Reproduced at this branch's HEAD from a clean bun install --frozen-lockfile in a scratch worktree, using the same command eas-dev.sh runs (eas fingerprint:generate -p ios --build-profile development-simulator, without EXPO_PUBLIC_*):

installfingerprint
bun 1.3.1401c85500dc2cfe18731792da3b7498af320743a6: exactly the "local machine" runtime of the failed builds
bun 1.4.29245768a665fbc158a16bdc248da6532799346c8: what EAS resolved for those builds
bun 1.3.14, then bun install with 1.4.2 on top9245768a…: a reinstall with the right bun is enough to recover

--os/--cpu overrides (linux-arm64, darwin-arm64), non-frozen and --production installs all give 6dc057…, so platform and install flags do not cause it.

Fix

scripts/postinstall.sh now warns on stderr when bun --version differs from .bun-version, and tells you how to recover (install the pinned bun, then rm -rf node_modules && bun install). It only warns, because developers on a newer bun can still install. Nothing is ignored in the fingerprint: the store path is the only input that differs, and fingerprint config cannot rewrite a path without skipping all autolinked native modules.

A box that is already on the right bun needs no change. This box (image of 2026-10-15, bun 1.4.2) already gets the EAS hash.

Verification

  • Hashes on this box at 19cecc9c and on EAS:
    • This box: 9245768a665fbc158a16bdc248da6532799346c8.
    • EAS: build 47f68dac (commit c1d34872, the latest finished development-simulator build) records 9245768a665fbc158a16bdc248da6532799346c8.
    • EAS also resolved 9245768a… for both builds of 035965bc, the commit the sandbox failed on.
    • No EAS build exists of this exact commit, and I did not start one.
  • apps/mobile/scripts/eas-dev.sh with no MOBILE_EAS_BUILD_ID: it installed 47f68dac without starting a build, and the app loaded from Metro (signed-in home screen). I stopped the session afterwards.
  • The warning prints under bun 1.3.14 and stays silent under 1.4.2.
  • bun test apps/mobile/eas-runtime-version.test.ts: 3 pass.

Note: the dev menu shows runtime 0462196c…. That is Metro's manifest, which is computed with the dev .env loaded. It is not the build's runtime, and the build lookup does not use it.

Follow-ups (other owners)

  • packages/sandbox: install the pinned bun from the bundle, not only the image, so older boxes are upgraded.
  • apps/mobile/scripts/eas-dev.sh: before the fingerprint lookup, stop when bun --version differs from .bun-version, instead of starting a build that will fail.

Summary by cubic

Fixes a silent mismatch between the bun version used during install and the one pinned in .bun-version, which caused apps/mobile to compute a different development-simulator fingerprint than EAS, making eas-dev.sh start a build that failed at "Configure expo-updates". The root cause is that cloud boxes keep the bun from their image, which can be older. scripts/postinstall.sh now warns on stderr when bun version differs and explains how to recover (install the pinned bun, then rm -rf node_modules && bun install). It only warns; the install still succeeds.

Summary by CodeRabbit

  • Installation
    • The install process now checks whether your Bun version matches the project’s pinned version. If they differ, it prints the expected version and suggested reinstall commands; installation continues without interruption.