Metro cache: the fix that isn't always --reset-cache
When the bundler shows yesterday's code, clearing the Metro cache is only one of four places a stale result can hide.
Hammad Iqbal
Software Engineer
A change you saved is not showing up in the app, or an error you already fixed keeps coming back. The reflex is to restart with --reset-cache. Sometimes that works, and sometimes it does not, because Metro's cache is only one of several layers that can serve stale output.
- Check whether the app is even connected to the Metro you think it is.
- Watchman, node_modules, and the native build each keep their own state.
- Change one layer at a time so you learn which one was stale.
Is the app talking to the right bundler
Before clearing anything, confirm the device is loading from your running dev server. An old dev server on the same port, or a release build installed over the debug one, produces exactly the 'my change does nothing' symptom.
The other caches
Each layer fails in a different way, which is useful: the symptom usually tells you which one to suspect.
- Watchman can miss file events after a branch switch; restart it
- A half-updated node_modules after a lockfile change needs a clean install
- Native changes need a rebuild, because Metro only bundles JavaScript
Clear one layer at a time
Wiping everything at once fixes the problem and teaches you nothing. Clearing one layer and retesting turns a mysterious bug into a known cause, and the next time it takes thirty seconds.
Stale output has several possible homes. Find which layer is stale instead of deleting all of them.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.