HMR broken for expo/babel: adding new strings requires expo start --clear

[k0d13]

HMR doesn't pick up newly added strings when using the babel plugin with Expo. Adding a new string requires a full restart with expo start --clear, which is slow.

I've made attempts to fix this in packages/plugin-babel/src/index.ts#L66, but they haven't worked. IIRC the issue is addExternalDependency erroring due to some frozen array caused by the Expo preset.

[k0d13]

@claude do you have any ideas with your knowledge of babel plugins?

[claude]

Claude finished @k0d13's task in 4m 43s —— View job

---

Investigating HMR issue

• Read the issue and referenced code (packages/plugin-babel/src/index.ts)
• Understand how addExternalDependency / Metro dependency graph works
• Identify why Expo preset causes a frozen array error
• Share ideas / next steps

---

Ideas on the addExternalDependency / HMR problem

What addExternalDependency is actually for. It's a Babel 7 API (packages/plugin-babel/src/index.ts:66) that lets a plugin tell the bundler "my output for this file also depends on the content of this other file, even though there's no require/import for it in the AST." It was added primarily for babel-loader — webpack reads result.externalDependencies off the transform result and calls this.addDependency(dep) on the loader context so its watcher knows to invalidate.

Metro likely doesn't consume it at all. This is the part worth verifying once you have node_modules installed: Metro builds its dependency graph by statically walking the transformed AST for require(...)/import calls (collectDependencies in metro), not by reading Babel's externalDependencies metadata off the transform result the way webpack does. You can confirm this yourself with:

grep -r "externalDependencies" node_modules/metro-transform-worker node_modules/metro/src

If that comes up empty (which matches my recollection of Metro's source), then even a successful addExternalDependency call would be a no-op under Metro — the frozen-array error is a red herring in the sense that fixing it wouldn't fix HMR.

Why this matches your symptoms exactly. Look at what the ImportDeclaration visitor does (index.ts:72-83): it fully replaces import m from './messages.json' with an inlined t.objectExpression. There is no require/import left in the output pointing at the catalogue source. So from Metro's perspective, the importing file (e.g. i18n.ts) has zero dependency edges to messages.json — Metro has no signal that its transform cache entry for i18n.ts is stale when only the catalogue file changes. i18n.ts's own content and static dependency list are unchanged, so Metro happily serves the stale cached transform. expo start --clear "fixes" it only because it nukes Metro's entire persistent cache, forcing every file to re-transform.

On the "frozen array" specifically — plausible cause: examples/expo/babel.config.js:8 calls api.cache(true) at the top level, which permanently caches the resolved plugin/preset chain for the whole process. Some versions of @babel/core's config-chain caching freeze cached descriptor objects to stop mutation leaking across cached calls, and if that overlaps with how babel-preset-expo/@react-native/babel-preset structure their plugin options, a later .push()/mutation inside addExternalDependency can hit a non-extensible object. Worth confirming precisely by removing the catch {} temporarily and logging error.stack — that'll tell us for certain whether it's this or something else, and is a 2-minute change once you can run expo start.

Suggested direction for an actual fix, independent of the error: give Metro a real dependency edge to the catalogue source(s), since that's the only thing Metro's graph understands. Concretely, alongside the inlined object, emit a guarded require(importeePath) (or keep the import but mark it side-effect-only) so Metro's collectDependencies pass picks up the edge and correctly invalidates/Fast-Refreshes dependents when the file changes:

if (process.env.NODE_ENV !== 'production') {
  require('./messages.json'); // phantom dependency so Metro's graph tracks this file
}

gated so production bundles don't pull in every locale file. This would need to be conditional on the bundler (Metro only) since Rollup/webpack/Vite already get correct invalidation today via addExternalDependency/their own watchers — so this isn't a universal fix, just a Metro-specific escape hatch.

I wasn't able to install dependencies or run expo start in this sandbox (no network access to fetch node_modules), so I can't confirm the exact frozen-array stack trace or verify Metro's source directly — the above is my best reasoning from the code and Babel/Metro's documented behavior. Happy to implement the require()-based workaround if you want to try it, or dig further once you can share the actual error stack from removing the catch {}.