[eas-cli] add --with-eas-environment-variables-set flag to eas update command

[szdziedzic]

Why

https://exponent-internal.slack.com/archives/C013ZK4SA12/p1725644220583309

We are planning to introduce enhancements to our env vars system soon. Currently, we only allow people to keep secrets on EAS servers. Secrets are not readable outside of EAS servers so of course EAS Update doesn't work with them. In a new system, people can also store readable env vars on our servers, which opens new possibilities about how EAS Update can interact with env vars!

In this PR I'm adding support for the --with-eas-environment-variables-set production|preview|development flag. If used, we use the flag's value to fetch readable env vars from our servers and use it in the expo export command to produce an update bundle based on these env vars. If the flag is used I'm using the EXPO_NO_DOTENV flag to disable Expo CLI from loading env vars from .env files and potentially unwillingly overwriting env vars fetched from our servers for a given environment.

Users seem to face big issues with using env vars with EAS Build & Update at the moment, originating from the fact that these 2 handle different, non-compatible ways of using env vars. Env vars in the build profile and server-side secrets vs local env vars + .env. With this flag it will be easy to avoid envs mismatch by doing eas update ----with-eas-environment-variables-set environment and eas build with `{ ..., environment: environment, ...} in the build profile!

How

Add a new hidden (for now) flag --with-eas-environment-variables-set that indicates which environment to use. If used fetch env vars from server. Merge and overwrite process.env with newly fetched env vars. Use them to resolve the expo config. Don't use .env env var loading from Expo CLI if server-side env vars are used.

Test Plan

Test manually. Run eas update with and without a new flag. Check that the expo config is resolved correctly.

[szdziedzic]

• [eas-cli] add simplified projectId-focused context #2653
• [eas-cli] add --with-eas-environment-variables-set flag to eas update command #2628 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @szdziedzic and the rest of your teammates on Graphite

[codecov]

Codecov Report

Attention: Patch coverage is 27.90698% with 62 lines in your changes missing coverage. Please review.

Project coverage is 52.93%. Comparing base (214cff0) to head (dc66b58).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
...xtUtils/loadServerSideEnvironmentVariablesAsync.ts	20.84%	19 Missing ⚠️
...text/ServerSideEnvironmentVariablesContextField.ts	38.89%	11 Missing ⚠️
...dUtils/context/DynamicProjectConfigContextField.ts	16.67%	10 Missing ⚠️
...ontext/OptionalPrivateProjectConfigContextField.ts	22.23%	7 Missing ⚠️
packages/eas-cli/src/project/publish.ts	0.00%	6 Missing ⚠️
packages/eas-cli/src/commands/update/index.ts	54.55%	4 Missing and 1 partial ⚠️
packages/eas-cli/src/utils/expoCli.ts	0.00%	3 Missing ⚠️
packages/eas-cli/src/commands/worker/deploy.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2628      +/-   ##
==========================================
- Coverage   53.05%   52.93%   -0.11%     
==========================================
  Files         566      569       +3     
  Lines       21615    21722     +107     
  Branches     4236     4259      +23     
==========================================
+ Hits        11466    11497      +31     
- Misses      10119    10194      +75     
- Partials       30       31       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Size Change: +3.67 kB (+0.01%)

Total Size: 53 MB

Filename	Size	Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz	53 MB	+3.67 kB (+0.01%)

_{compressed-size-action}

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@khamilowicz, @sjchmiela
packages/eas-cli/src/commands/build/**	@khamilowicz, @sjchmiela
packages/eas-cli/src/commands/update/**	@EvanBacon, @byCedric, @wschurman

Generated by CodeMention

[wschurman]

I wonder if maybe this should live up a level in the contexts to better indicate where this flag might be necessary to apply (which commands it needs to be added to for consistency)? (DynamicPublicProjectConfigContextField, PrivateProjectConfigContextField, OptionalPrivateProjectConfigContextField). As it stands, I think we would at least need to add it to a few other update commands (roll-back-to-embedded, etc) in case the config resolved in those commands also depends on these env variables, which makes me think this might be good to move into the contexts. I might be wrong though. What do you think?

[szdziedzic]

@wschurman @quinlanj I moved server side env vars fetching to context functions. This way they will be used every time when one class getExpoConfig function if withServerSideEnvironment context resolution option is set. It will be easier to not forget about using them for resolving config.

I also added a context option to get a function that will fetch server side env vars for given project and environment.

Please let me know what you think about it now 🙏

If it looks OK, I will add the same flag and logic to the rest of eas update:xyz commands.

[wschurman]

One inline comment. Also I believe we also need to add this to OptionalPrivateProjectConfigContextField?

For the follow-up PR that adds the argument elsewhere, I think there's a good chance we'll need to add the withServerSideEnvironment argument to every command that uses any of (DynamicProjectConfig, ProjectConfig, OptionalProjectConfig, ServerSideEnvironmentVariables) contexts? Maybe there's a clever way we could use typescript to enforce that the argument is supplied when any of those fields is used.

[szdziedzic]

Also I believe we also need to add this to OptionalPrivateProjectConfigContextField?

Added 🫡

For the follow-up PR that adds the argument elsewhere, I think there's a good chance we'll need to add the withServerSideEnvironment argument to every command that uses any of (DynamicProjectConfig, ProjectConfig, OptionalProjectConfig, ServerSideEnvironmentVariables) contexts? Maybe there's a clever way we could use typescript to enforce that the argument is supplied when any of those fields is used.

@wschurman believe I was able to do so. Can you take a look once again please?

[szdziedzic]

I made withServerSideEnvironment required but nullable when dynamic project config or server-side env vars are used. I will change this value from null to some real environment for all other commands in separate PR when it's easier to test and control it for me in a limited scope.

[wschurman]

Awesome use of types! Made a few small adjustments but overall it's really cool to be able to have the typechecker tell us where this is needed.

Side note: I think we need to add the variable fetching code to PrivateProjectConfigContextField as well?

[wschurman]

I see that if we add it to PrivateProjectConfigContextField and make it's context require the withServerSideEnvironment argument as I proposed, it reveals quite a number of commands that need it.

Looking at the commands though, I see a number of them just get the projectId out of the privateProjectConfig, so this might signal that a new context is needed that is the same as ProjectConfig but only exposes the projectId?

[wschurman]

(assuming projectId is not allowed to be altered via a server-side environment variable since that'd be wonky)

[szdziedzic]

(assuming projectId is not allowed to be altered via a server-side environment variable since that'd be wonky)

Yeah, it should not be altered, this would be weird because we would load env vars for project X and then evaluate project ID for project Y.

I see that if we add it to PrivateProjectConfigContextField and make it's context require the withServerSideEnvironment argument as I proposed, it reveals quite a number of commands that need it. Looking at the commands though, I see a number of them just get the projectId out of the privateProjectConfig, so this might signal that a new context is needed that is the same as ProjectConfig but only exposes the projectId?

I will add new context, thanks for the advice!

[szdziedzic]

@wschurman I added a separate PR in which I add new context

[github-actions]

❌ It looks like a changelog entry is missing for this PR. Add it manually to CHANGELOG.md.
⏩ If this PR doesn't require a changelog entry, such as if it's an internal change that doesn't affect the user experience, you can add the "no changelog" label to the PR.

[szdziedzic]

Merge activity

• Oct 25, 8:18 AM EDT: A user started a stack merge that includes this pull request via Graphite.
• Oct 25, 8:19 AM EDT: A user merged this pull request with Graphite.