Unable to set eas version on eas workflows

[pfe-nazaries]

Build/Submit details page URL

No response

Summary

Hi guys,

im following your docs suggestions to set explicit eas version for my project.

There are three places where i need to fill the version in order to eas not complain when a new version is released

eas.json

{
    "cli": {
        "version": "16.6.1",
    },
}

GIthub actions

            - name: Setup EAS
              uses: expo/expo-github-action@v8
              with:
                  eas-version: 16.6.1
                  token: ${{ secrets.EXPO_TOKEN }}

Eas workflows

jobs:
    publish_preview_update:
        name: Publish preview update
        type: update
        environment: preview
        version: 16.6.1
        params:
            branch: ${{ github.ref_name || 'test' }}

This is the one that is not working for me. I tried the same key property from github actions and eas.json but didnt work. I cant find anything related to that here https://docs.expo.dev/eas/workflows/syntax/

And each time a eas cli version is released this last workflow fails until i upgrade the version. So is forcing me instead of leave me the choice when to upgrade.

Could you provide some help here and maybe update the docs for eas workflows?

My other guess was to setup up here https://docs.expo.dev/eas/workflows/syntax/#defaultstools but no single mention to eas cli

Thank you

Managed or bare?

Managed

Environment

expo-env-info 1.3.3 environment info: System: OS: macOS 15.4.1 Shell: 3.2.57 - /bin/sh Binaries: Node: 20.18.0 - ~/.nvm/versions/node/v20.18.0/bin/node Yarn: 1.22.22 - ~/.nvm/versions/node/v20.18.0/bin/yarn npm: 10.8.2 - ~/.nvm/versions/node/v20.18.0/bin/npm Watchman: 2025.04.28.00 - /opt/homebrew/bin/watchman SDKs: iOS SDK: Platforms: DriverKit 24.4, iOS 18.4, macOS 15.4, tvOS 18.4, visionOS 2.4, watchOS 11.4 IDEs: Android Studio: 2024.3 AI-243.24978.46.2431.13208083 Xcode: 16.3/16E140 - /usr/bin/xcodebuild npmPackages: expo: 53.0.9 => 53.0.9 expo-router: ~5.0.7 => 5.0.7 expo-updates: ~0.28.13 => 0.28.13 react: 19.0.0 => 19.0.0 react-dom: 19.0.0 => 19.0.0 react-native: 0.79.2 => 0.79.2 react-native-web: 0.20.0 => 0.20.0 Expo Workflow: bare

12/15 checks passed. 3 checks failed. Possible issues detected: Use the --verbose flag to see more details about passed checks.

✖ Check that native modules use compatible support package versions for installed Expo SDK Expected package metro@^0.82.0 Found invalid: [email protected] (for more info, run: npm why metro) Expected package metro-resolver@^0.82.0 Found invalid: [email protected] [email protected] (for more info, run: npm why metro-resolver) Expected package metro-config@^0.82.0 Found invalid: [email protected] (for more info, run: npm why metro-config) Advice: Upgrade dependencies that are using the invalid package versions.

✖ Check native tooling versions Cocoapods version check failed. Cocoapods may not be installed or there may be an issue with your Cocoapods installation. Installing version 1.15.2 or higher is recommended. Advice: Update your native tooling to the recommended versions.

✖ Validate packages against React Native Directory package metadata The following issues were found when validating your dependencies against React Native Directory: Untested on New Architecture: i18next No metadata available: @gluestack-ui/actionsheet, @gluestack-ui/button, @gluestack-ui/checkbox, @gluestack-ui/form-control, @gluestack-ui/icon, @gluestack-ui/input, @gluestack-ui/nativewind-utils, @gluestack-ui/overlay, @gluestack-ui/select, @gluestack-ui/textarea, @gluestack-ui/themed, @gluestack-ui/toast, @hookform/resolvers, @legendapp/motion, es-toolkit, i18next-browser-languagedetector, i18next-http-backend, inversify, luxon, mobx-react, neverthrow, reflect-metadata, rxjs, tailwind-variants, uuid, zod-i18n-map, zod_utilz
Advice: Use libraries that are actively maintained and support the New Architecture. Find alternative libraries with https://reactnative.directory. Add packages to expo.doctor.reactNativeDirectoryCheck.exclude in package.json to selectively skip validations, if the warning is not relevant. Update React Native Directory to include metadata for unknown packages. Alternatively, set expo.doctor.reactNativeDirectoryCheck.listUnknownPackages in package.json to false to skip warnings about packages with no metadata, if the warning is not relevant.

3 checks failed, indicating possible issues with the project.

Error output

No response

Reproducible demo or steps to reproduce from a blank project

Just asking for docs

[kadikraman]

I can't quite tell what command you're running there - do you have an npx expo-doctor check on your CI? If so, pinning the EAS CLI version would not make a difference for this issue.

But you can use EXPO_DOCTOR_SKIP_DEPENDENCY_VERSION_CHECK=1 npx expo-doctor which will skip warning you about the dependency updates.

[pfe-nazaries]

I can't quite tell what command you're running there - do you have an npx expo-doctor check on your CI? If so, pinning the EAS CLI version would not make a difference for this issue.

But you can use EXPO_DOCTOR_SKIP_DEPENDENCY_VERSION_CHECK=1 npx expo-doctor which will skip warning you about the dependency updates.

Hi,

it is not the expo doctor command who fails, it is the expo update command who fails on my workflow each time a new eas CLI version is released and is newest to the one locked on my eas.json file.

That's why I'm asking about the flag, name or support to also lock the eas CLI version used on the eas workflows. Im using the preview workflow sample from your docs: https://docs.expo.dev/eas/workflows/examples/#preview-updates-workflow

Because without that support, locking the version on eas.json is pointless, it will force me to change it on every eas release instead of letting me choose when to upgrade

[pfe-nazaries]

Hi @kadikraman, could you point on the right direction about that on eas workflows?

[sjchmiela]

version in eas.json supports semver. Can you prepend the version you're trying to specify with >= (>=16.6.1)?

Why would you want to specify a single strict version? When you execute eas-cli commands in your workflow steps you can always do npx eas-cli@... to use a specific eas-cli version.

[pfe-nazaries]

Hey @sjchmiela

I always pin my dependencies, not all packages really always follow semver changes on their semver versions.

Anyway, where I can't specify the version is on special files from eas called eas workflows (not GitHub actions or any other ci tool)

This is the file from the docs https://docs.expo.dev/eas/workflows/examples/#preview-updates-workflow

And here is the full config object for an eas workflow https://docs.expo.dev/eas/workflows/syntax/

name: Publish preview update

defaults:
    tools:
        bun: 1.2.13

on:
    push:
        branches: ["*"]

jobs:
    publish_preview_update:
        name: Publish preview update
        type: update
        environment: preview
        params:
            branch: ${{ github.ref_name || 'test' }}

There is no reference on the docs on how to set the eas version like I can do, for example, for bun.

So the request could go in two different ways:

1. Add to the eas workflow config object the eas version option
2. Eas workflow should always use the version specified on eas.json instead of the latest version available
3. Both

The second option is more correct from my perspective

[jonsamp]

Hi @pfe-nazaries, as you noticed, it's not possible to set a specific version of EAS CLI on our pre-packaged jobs, like type: update. We need to use specific versions of EAS CLI so that we can ensure those jobs work consistently. If we allowed users to change that, we might break your CI flows at unplanned times in the future. So, we don't allow altering that on our pre-packaged jobs.

With that, if you need to set a specific EAS CLI version to publish an update, like version 16.6.1, you could run a custom job like this:

name: Example

jobs:
  custom_update_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: npx [email protected] update --auto --non-interactive

[alexbaileyuk]

Just come across this same version. Feels kind of crazy that we can't pin a version. Agree that this should be read from eas.json. Could the pre-packaged jobs simply have minimum supported versions? How would we know what version is included in the job today and ensure consistency when running EAS commands outside of the workflows?

[sjchmiela]

How would we know what version is included in the job today and ensure consistency when running EAS commands outside of the workflows?

Can you elaborate?

[pfe-nazaries]

How would we know what version is included in the job today and ensure consistency when running EAS commands outside of the workflows?

Can you elaborate?

I think the response that you are looking from @alexbaileyuk is already described by me on the issue initial message.

Let me know if you need more details