Steps to fix/diagnose changes to App.js not being picked up in Expo Go?

Our project is in a state where expo does not detect any changes made to the code unless “expo start” is killed and re-run. I’ve compared it very carefully with a brand new empty project generated by “expo init”, but can’t seem to find any differences.

I’m hoping to find three pieces of information to assist in debugging this.

  1. Any known interaction issues between expo 45.0.4, expo Go version 2.24.4, expo-cli version 5.4.6, node 16.15.0, and Windows 11?

  2. A comprehensive list of cache directories that may need to be cleared out. The ones I’m aware of are ~/.expo, the project local .expo, the project local node_modules, and any data that Expo Go stores on the emulator.

  3. Ways to trace and check for failures after saving a file. Say I add a Test element to App.js and save the file. What are the necessary steps that happen after saving before the changes appear in Expo Go? Is there any way for to trace them without building expo-cli from scratch? The step that I can consistently trace is a call to app.config.js, but after that it seems like nothing happens and no errors are shown.

One piece of info I do notice. If I create an error in App.js, say by adding “throw new Error(‘some error’)”, start fresh by running “expo start”, the error will come up. Then if I remove the error, the code continues to fail, but Expo Go in the stack trace shows the error line as having been removed from the source.

So Expo Go seems to be aware of the correct source code on the file system, but the process that builds the binaries is not.

I think it may be tied to use of the React Context type. If we take a bare-bones project and add a context to it, it seems to mess up the dynamic refresh until we completely nuke all imaginable files and folders related to the Android emulator and Expo project.

Cache folders that possibly matter:


We also tried down-grading the Android API to 30 from 32. Don’t believe that makes a difference.

Very odd.

Have you tried restarting your computer?
Or copying over all your application code, bit by bit, to see if you can isolate where the problem comes up?

Sorry you are having this issue. It sounds frustrating.

Yeah I’ve rebooted several times during the process of debugging this. I may have narrowed it down more to a React Context that used Sentry, which used expo-constants.

I’m seeing if I can narrow the issue down to having added expo-constants.

OK here is some extra info:

  1. Web mode works just fine.

  2. Web mode on the same emulator I’m trying to get Expo Go working on, works just fine. (That is, I can run the app from the emulator web browser and see the changes.)

  3. In “adb logcat”, I am seeing this exception when I try to reload and am wondering if it’s indicative of anything:

> 06-02 09:23:18.032 5171 5376 E unknown:ReactContextBaseJavaModule: Unhandled SoftException
> 06-02 09:23:18.032 5171 5376 E unknown:ReactContextBaseJavaModule: java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by WebSocketModule
> 06-02 09:23:18.032 5171 5376 E unknown:ReactContextBaseJavaModule: at
> 06-02 09:23:18.032 5171 5376 E unknown:ReactContextBaseJavaModule: at
> 06-02 09:23:18.032 5171 5376 E unknown:ReactContextBaseJavaModule: at$100(

We’ve narrowed this down to our having an environment variable BUILD_NUMBER, which apparently screws up either Expo or possible some dependent module.

We’ll file a bug report as it’s actually pretty easy to recreate the issue.

we don’t do anything with such an environment variable, so it might be in some other tool. if you can share a minimal project where it’s possible to repro it let us know.

Yeah I was a bit fascinated by the issue because a quick search of BUILD_NUMBER in Expo and React-Native didn’t turn up anything obvious.

It’s really easy to recreate. Just create a fresh project and set the env var BUILD_NUMBER to some value before running “expo start”. I suspect it’ll work in existing projects as well.

1 Like

ah i see what is happening. metro depends on the ci-info package which uses BUILD_NUMBER to check if you’re on CI: ci-info/index.js at 8a6aee332a57d92d30ab0c5f7f3422dc2b0a31b8 · watson/ci-info · GitHub


This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.