Beta version of expo-cli is unintendedly executed when using new expo 45 project template

[steve192]

Summary

When a new project is created with expo init (version 5.4.3 of globally installed expo-cli) a new sdk 45 project is created. When you run npx expo --version, version 0.1.4 of expo-cli is executed.

# npx expo --version
0.1.4

The same applies when running npm run start. This leads to many features of expo-cli missing (like developer console, tunnels etc.)

When you run npx expo-cli --version the correct version of expo-cli is executed

# npx expo-cli --version
5.4.3

Environment

# npx expo-env-info
Need to install the following packages:
  expo-env-info
Ok to proceed? (y) y

  expo-env-info 1.0.3 environment info:
    System:
      OS: Linux 5.10 Ubuntu 20.04.4 LTS (Focal Fossa)
      Shell: 5.0.17 - /bin/bash
    Binaries:
      Node: 16.14.2 - ~/.nvm/versions/node/v16.14.2/bin/node
      npm: 8.8.0 - ~/.nvm/versions/node/v16.14.2/bin/npm
    npmPackages:
      expo: ~45.0.0 => 45.0.2 
      react: 17.0.2 => 17.0.2 
      react-dom: 17.0.2 => 17.0.2 
      react-native: 0.68.1 => 0.68.1 
      react-native-web: 0.17.7 => 0.17.7 
    npmGlobalPackages:
      expo-cli: 5.4.3
    Expo Workflow: managed

Please specify your device/emulator/simulator platform, model and version

WSL on Windows 11, no device needed

Error output

Not applicable

Reproducible demo or steps to reproduce from a blank project

Create new expo project with expo init and run npx expo --version

[steve192]

Also seems to apply to a "neutral" build environment: https://github.com/steve192/opencookbook-frontend/runs/6377374686?check_suite_focus=true

Here the expo build:web command fails, probably because this command was not included in expo-cli 0.1.4

[raajnadar]

It seems you are using the new expo cli that is shipped with the expo packages.

https://github.com/expo/expo/tree/main/packages/%40expo/cli

The version you gave and the version in the repo looks same.

[ide]

@raajnadar is correct. This is a side effect of the new CLI, which is much smaller and comes with the expo package. In other words, every Expo project now gets its own copy of the CLI. This way older projects are more likely to keep working even if the CLI changes over time and it's also easier for us to make breaking changes to the CLI in a stable way that doesn't affect existing projects.

More info here:

• SDK 45 release notes: https://blog.expo.dev/expo-sdk-45-f4e332954a68#a7a8
• "Versioned" Expo CLI intro: https://blog.expo.dev/new-versioned-expo-cli-cf6e10632656

This affects running expo in two ways: with npx and via package.json scripts. npx expo and package.json scripts first look for locally installed packages before global ones.

One workaround as you mentioned is to invoke expo-cli instead of expo. This is probably the most reliable solution.

[steve192]

Oh I see. Thanks for the links. Is it correct that the beta cli should only be enabled when EXPO_USE_BETA_CLI=1 is set? I did not set this env. I would expect that the locally installed expo-cli is picked up instead of the new beta one bundled in expo.

[ide]

I'm not sure without investigating further. @EvanBacon maybe @expo/cli shouldn't specify a "bin" field in package.json and only expo should be responsible for invoking @expo/cli?

[EvanBacon]

I haven't encountered this behavior before, perhaps the project is using an older beta patch of expo which exposed the CLI directly (before we added the env variable), or expo isn't installed and @expo/cli is installed. I can drop the bin but realistically we'd be adding it back since this will be ~2x faster than going through the expo package. We plan for a stable release at the end of July.

[steve192]

@EvanBacon I think it will not matter much which locally installed cli is executed when the new cli exits it's beta and supports all the features of the old cli. Currently the problem is more that suddenly the cli that is executed by npx expo / npm run start does not have all features like the developer tools (thats also where I noticed this behavior, they were just gone)

When you would want to use a specific version of the cli independent from the locally installed expo version in the future, you could still install it globally (which should not be the normal usecase)

[EvanBacon]

@steve192 npx expo is not an official way to use expo-cli (a global CLI). You can use npx expo-cli to circumvent the local behavior. We are merging a change today which temporarily makes it more difficult to use the beta CLI, but this will only last for two or so months.

Currently the problem is more that suddenly the cli that is executed...

This behavior should not be sudden, it only occurs after performing a major version bump of Expo from 34 to 35 in your project manually.

When you would want to use a specific version of the cli independent from the locally installed expo version in the future, you could still install it globally

We won't be officially supporting this at all in the future. We've split out all of the unversioned commands into global tools like eas-cli, create-expo-app, etc. The remaining commands are specifically tied to the versions of babel, metro, react, jest, typescript, etc. that are inside your project, it's important that features like expo start are versioned with your project.

You could unofficially hack around this by using 'yarn resolutions' to change the installed version of @expo/cli for your project, but I don't recommend doing this.

[brentvatne]

@steve192 - I updated the release notes accordingly:

If you use npx expo inside of your project (for example, on CI to skip installing Expo CLI globally), we recommend changing it to npx expo-cli to prevent accidentally invoking the new, beta, local CLI.

[steve192]

Thank you guys for your support. From my side we can close this issue as the behavior is clarified