eas update missing --clear-cache option

[jkk]

Build/Submit details page URL

https://expo.dev/accounts/kavyar-org/projects/kavyar-app/updates/d58a32ad-7c5a-4122-8def-29c85401bb7d

Summary

eas update seems to be missing a --clear-cache option. expo publish had this option and eas build has it. Not having it is causing problems with our app updates.

We are using a STAGE environment variable to auto-configure our app for the appropriate release environment (dev, staging, production). We inject it into the app using eas.json, app.config.js, and the Constants.manifest2?.extra?.expoClient?.extra?.eas?.STAGE technique recommended in the docs.

This works fine for the initial EAS build. However, when we do eas update, the generated bundle will often have a stale value (from a prior build) for the STAGE var that gets injected via Constants.

We used to use the --clear option with expo publish to work around this, but that option is not available for eas update.

This recently caused a staging config to be released into our production app, which created quite a mess.

Managed or bare?

Managed

Environment

  expo-env-info 1.0.3 environment info:
    System:
      OS: macOS 12.2.1
      Shell: 5.8 - /bin/zsh
    Binaries:
      Node: 14.18.1 - ~/.nvm/versions/node/v14.18.1/bin/node
      Yarn: 1.22.18 - /opt/homebrew/bin/yarn
      npm: 6.14.15 - ~/.nvm/versions/node/v14.18.1/bin/npm
    SDKs:
      iOS SDK:
        Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
      Android SDK:
        API Levels: 31
        Build Tools: 31.0.0, 32.0.0
        System Images: android-31 | Google APIs ARM 64 v8a
    IDEs:
      Android Studio: 2020.3 AI-203.7717.56.2031.7784292
      Xcode: 13.4/13F17a - /usr/bin/xcodebuild
    npmPackages:
      babel-preset-expo: ~9.1.0 => 9.1.0 
      expo: ^45.0.0 => 45.0.4 
      react: 17.0.2 => 17.0.2 
      react-dom: 17.0.2 => 17.0.2 
      react-native: 0.68.2 => 0.68.2 
      react-native-web: 0.17.7 => 0.17.7 
    npmGlobalPackages:
      eas-cli: 0.52.0
      expo-cli: 5.4.7
    Expo Workflow: managed

Error output

No response

Reproducible demo or steps to reproduce from a blank project

Hopefully the issue is clear enough not to need an isolated reproduction. If a reproduction is required, let me know and I will see if our team has time to create one.

[kbrandwijk]

You are right that such an option doesn't exist yet, and that this will cause issues when only environment variables are updated, making the bundler think nothing has changed. We are looking into the best solution for this internally, but in the meantime, there is a workaround.

You can run ~~expo export --experimental-bundle --clear-cache~~, which will force the dist folder to be updated. After that, running eas update as normal will use the updated bundle for the update.

Update: as pointed out below, it's expo export --experimental-bundle --clear

[antidiestro]

@kbrandwijk It seems like the command option is actually --clear and not --clear-cache.

[SleeplessByte]

I also ran into this (this is still tagged as need review) and it has actually broken our production envs a few times as well as leaking development and test values into production apps.

Even if you log in app.config.ts env-provided values, the dist folder will have still the old data. Even purging the dist folder before building still generated the old data, meaning that (likely) the bundler holds some transform cache somewhere, probably relating to babel.

expo export --experimental-bundle --clear

whilst this seems to maybe work consistently, doesn't this force an extra build? Or will the eas update afterwards just pick up that build instead?

[90dy]

Same issue as @SleeplessByte,

My proposal (from top priority):

When using eas update, the cache should be cleared and the command should create a new bundle:

1. Based on the babel cache feature api.cache
2. If dist folder or --input-folder value doesn't exists
3. If eas.json build profile env are different

Thx

PS: @SleeplessByte

whilst this seems to maybe work consistently, doesn't this force an extra build? Or will the eas update afterwards just pick up that build instead?

If you run it with --skip-bundler: eas update --skip-bundler [...], it should not try to "rebundle" (even if it's currently not rebundling it anyway)

[SleeplessByte]

Thanks @90dy I'll try taht too.

For simplicity, if it created a new bundle if app.json (or the output of the dynamic version) changes, all these issues would go away.

[pochampagne]

Is there a short term work around for this issue ?

Does only expo export --experimental-bundle --clear do the trick ?

Or I have add this flag --skip-bundler to my update also ?

[jkk]

@pochampagne I don't know if it's 100% correct but this is the workaround we're using:

In package.json, we have these scripts:

{
  ...
  "scripts": {
    ...
    "publish:production": "yarn clear-react-native-cache && STAGE=production eas update --branch production",
    "clear-react-native-cache": "rm -rf $TMPDIR/react-* && rm -rf $TMPDIR/metro-*"
    ...
  },

Then we run yarn publish:production to do an EAS update release.

[pochampagne]

@pochampagne I don't know if it's 100% correct but this is the workaround we're using:

In package.json, we have these scripts:

{
  ...
  "scripts": {
    ...
    "publish:production": "yarn clear-react-native-cache && STAGE=production eas update --branch production",
    "clear-react-native-cache": "rm -rf $TMPDIR/react-* && rm -rf $TMPDIR/metro-*"
    ...
  },

Then we run yarn publish:production to do an EAS update release.

Thanks @jkk ! is your $TMPDIR any particular folder ?

[jkk]

@pochampagne it's a global env var on unix-like systems which points to a system temp directory - https://en.wikipedia.org/wiki/TMPDIR

[pochampagne]

@pochampagne it's a global env var on unix-like systems which points to a system temp directory - https://en.wikipedia.org/wiki/TMPDIR

Awesome thanks for the info !

[Spharian]

Any update on this?

[thiagoacmonteiro]

For me the problem is with my environment variables. When I'm running my project locally using local servers and I use eas update, the production app starts trying to make requests on localhost... What a mess.

[90dy]

My current workaround is just to run pkill -f expo; before running update The full command:

    "update:": "NODE_ENV=production pkill -f expo; expo export --experimental-bundle --clear --output-dir dist/${APP_BUILD}-${APP_ENV} && eas update --auto --branch=${BRANCH} --input-dir dist/${APP_BUILD}-${APP_ENV}",

[expo-bot]

Thank you for filing this issue! This comment acknowledges we believe this may be a bug and there’s enough information to investigate it. However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[quinlanj]

I've landed a PR that will add the a --clear-cache flag to eas update to clear the metro bundler cache. It will be available in the next patch release of eas-cli.

[nandorojo]

Thank you @quinlanj! Might make sense for --clear to be an alias to match up with expo start