EAS auto-fingerprint crashes with `(0 , brace_expansion_1.default) is not a function` after brace-expansion 5.0.6 publish (2026-05-08)

[toni-a11y]

Build/Submit form data

eas-cli/18.11.0 darwin-arm64 node-v20.19.4 (also reproduces on EAS Build cloud workers)

Summary

Starting today (2026-05-08), eas build crashes during the auto-fingerprint step with:

(0 , brace_expansion_1.default) is not a function

To skip this step, set the environment variable: EAS_SKIP_AUTO_FINGERPRINT=1

Builds that succeeded a few hours earlier now fail without any code change on our side. The trigger is an upstream npm publish of brace-expansion@5.0.6 (and @2.1.0 from 2026-04-11) that removes the CJS-friendly default export shape that minimatch@9.x/10.x consume via TypeScript's __importDefault helper.

Reproduction

Clean install on a project where @expo/fingerprint@0.15.4 (bundled by recent eas-cli) resolves minimatch@9.0.9 -> brace-expansion@2.1.0 (or minimatch@10.x -> brace-expansion@5.0.6):

pnpm install        # re-resolves transitive minimatch -> brace-expansion
eas build --profile preview --platform ios

Crashes inside @expo/fingerprint/node_modules/minimatch/dist/commonjs/index.js line 7:

const brace_expansion_1 = __importDefault(require("brace-expansion"));

__importDefault returns mod unchanged when mod.__esModule === true. brace-expansion 2.1.0 / 5.0.6 ship as ESM-only ("type": "module", named export only — no default), so brace_expansion_1.default is undefined.

Root cause

Upstream regression in brace-expansion:

Version	Published	Notes
2.0.2	2025-06-11	Last CJS-compatible 2.x
1.1.14	2026-04-11
2.1.0	2026-04-11	ESM-only, no default export
5.0.5	2026-03-24
5.0.6	2026-05-08	ESM-only, no default export

minimatch@9.0.9 and minimatch@10.2.x both still emit CJS dist/commonjs/index.js that does __importDefault(require("brace-expansion")) and calls .default(...). That worked against 2.0.x / 5.0.5 (CJS, wrapped by the helper into { default: expand }), but breaks against the new ESM publish (helper sees __esModule: true and skips wrapping).

This is a published-as-minor / published-as-patch breaking change in an upstream transitive — every consumer that re-resolves after the publish window inherits the break.

Why this hits EAS users specifically today

@expo/fingerprint declares minimatch: ^9.x (resolves to 9.0.9 -> brace-expansion 2.1.0) without a floor that blocks the regression. EAS Build runs pnpm install / npm install on the cloud worker; any project whose lockfile gets refreshed (or that has wildcard versions in package.json forcing re-resolution) picks up brace-expansion@5.0.6 / 2.1.0 and the auto-fingerprint step instantly fails.

Workarounds (confirmed)

In the consuming project root package.json:

{
  "pnpm": {
    "overrides": {
      "brace-expansion@>=2.1.0 <3": "2.0.2",
      "brace-expansion@>=5.0.6": "5.0.5"
    }
  }
}

(npm equivalent: top-level "overrides".)

Then pnpm install --frozen-lockfile (or commit the regenerated lockfile) and rebuild. EAS_SKIP_AUTO_FINGERPRINT=1 also unblocks builds but disables a feature, so it is not a real fix.

Suggested fix in eas-cli / @expo/fingerprint

One of:

1. Pin brace-expansion via @expo/fingerprint own package.json overrides / resolutions, so users on a fresh install get a working version regardless of npm registry state.
2. Bump minimatch (and rebuild against a tag that uses named imports — import { expand } from "brace-expansion" — so the new ESM shape is fine).
3. Vendor a small brace-expansion replacement; transitive churn from this dep has been a recurring source of EAS Build outages.

Happy to test a release candidate.

Environment

• eas-cli: 18.11.0
• @expo/fingerprint: 0.15.4 (transitively, bundled with eas-cli)
• expo: 54.0.33
• pnpm: 10.x
• Node: 20.19.4 (local); default Node on EAS Build workers reproduces the same.

[mateuszpazdan-dot]

Same issue here, blocking iOS production builds via Replit Publish