EAS should never use .env.local for builds or updates

[colinux]

Build/Submit details page URL

No response

Summary

EAS 14 now loads .env file but it also uses .env.local, which is intended to be local-only environment variables, not for other environments.

Managed or bare?

managed

Environment

expo-env-info 1.2.2 environment info:
    System:
      OS: macOS 14.7.1
      Shell: 5.9 - /bin/zsh
    Binaries:
      Node: 22.11.0 - ~/.nodenv/versions/22.11.0/bin/node
      Yarn: 3.1.1 - ~/.nodenv/versions/22.11.0/bin/yarn
      npm: 10.9.0 - ~/.nodenv/versions/22.11.0/bin/npm
      Watchman: 2024.12.02.00 - /opt/homebrew/bin/watchman
    Managers:
      CocoaPods: 1.16.2 - /Users/colin/.rbenv/shims/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 24.2, iOS 18.2, macOS 15.2, tvOS 18.2, visionOS 2.2, watchOS 11.2
    IDEs:
      Xcode: 16.2/16C5032a - /usr/bin/xcodebuild
    npmPackages:
      babel-preset-expo: ~11.0.0 => 11.0.14
      expo: ^51.0.39 => 51.0.39
      react: 18.2.0 => 18.2.0
      react-dom: 18.2.0 => 18.2.0
      react-native: 0.74.5 => 0.74.5
      react-native-web: ~0.19.6 => 0.19.12
    npmGlobalPackages:
      eas-cli: 14.4.1
    Expo Workflow: managed


› npx expo-doctor
✔ Check package.json for common issues
✔ Check Expo config for common issues
✔ Check native tooling versions
✔ Check if the project meets version requirements for submission to app stores
✔ Check for common project setup issues
✔ Check dependencies for packages that should not be installed directly
✔ Check for app config fields that may not be synced in a non-CNG project
(node:99240) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
✔ Check for issues with Metro config
✔ Check npm/ yarn versions
✔ Check Expo config (app.json/ app.config.js) schema
✔ Check that packages match versions required by installed Expo SDK
✔ Check for legacy global CLI installed locally
✔ Check that native modules do not use incompatible support packages
✔ Check that native modules use compatible support package versions for installed Expo SDK

Didn't find any issues with the project!

Error output

No response

Reproducible demo or steps to reproduce from a blank project

With a .env.local

eas update --branch staging --message "blah"
[expo-cli] env: load .env.local 
[expo-cli] env: export EXPO_PUBLIC_API_HOST EXPO_PUBLIC_WEBAPP_HOST

If .env file exists, it loads both.

In my case, it has updated local hosts in the staging builds because for some reason I don't configure these variables in eas.json (I may change that). But anyway, I believe .env*.local should strictly be limited to the local environment.

[melyux]

EAS Build --local should, though.

[AdamGerthel]

EAS Build --local should, though.

What? Why? The "local" flag is for running eas on your machine. That's completely different.

[melyux]

Because this is the eas-cli repo, and eas-cli also handles local builds. Wouldn't want the local version to be bunked up with a fix aimed at the cloud build

[AdamGerthel]

Personally, I'm not using EAS cloud service, I create all my builds using eas-cli on my laptop (i.e. using --local). I absolutely would not want it to read .env.local when I make production builds.

If you want it to read .env.local, then it would make more sense to do so if the profile was called "local", but that's completely different from --local

[melyux]

We use .env.local as an alternative to EAS Secrets, which aren't accessible in local builds. So they're required even for local production builds.

At least that was the case recently, there were some changes recently with those, but not sure if that situation has changed.