[eas-cli] use npx expo config command to resolve expo config if available

[szdziedzic]

Why

https://exponent-internal.slack.com/archives/C02123T524U/p1724970663050089?thread_ts=1724924614.773089&cid=C02123T524U
https://exponent-internal.slack.com/archives/C5ERY0TAR/p1725002816077089

Generally @expo/config, @expo/prebuild-config, and @expo/config-plugins are per SDK concept. Currently, in EAS CLI, we rely on one version of the @expo/... package to work well globally for all SDKs. It seems to sometimes bite us like in the case of https://exponent-internal.slack.com/archives/C02123T524U/p1724909908574979, because SDK 51 config wasn't compatible with SDK 50.

It's better to switch to using config-related functions shipped with @expo/config, @expo/prebuild-config, and @expo/config-plugins. I believe we can assume that getConfig, getPrebuildConfig, and compileModsAsync shipped with these packages have stable API https://exponent-internal.slack.com/archives/C5ERY0TAR/p1725293002128849?thread_ts=1725002816.077089&cid=C5ERY0TAR.

How

Use getConfig, getPrebuildConfig, and compileModsAsync from @expo/config, @expo/prebuild-config, and @expo/config-plugins shipped with Expo SDK installed in the user's project. If not available, fallback to versions installed per SDK. If we can assume that these guarantee stable API we can use types of these functions from packages installed for EAS CLI as well.

Test Plan

Run builds for repro case of https://exponent-internal.slack.com/archives/C02123T524U/p1724909908574979 with SDK 51 config packages installed for EAS CLI (that previously broke it), see that it works and capabilities are correctly synced.

Initiate a new bare RN project using community CLI, and check that it works as well using fallback config loading.

[szdziedzic]

• [eas-cli] update expo packages #2530
• [eas-cli] use npx expo config command to resolve expo config if available #2529 👈
• [eas-cli] remove @expo/config-types dependency #2528
• main

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

Join @szdziedzic and the rest of your teammates on Graphite

[github-actions]

Size Change: -146 B (0%)

Total Size: 53 MB

Filename	Size	Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz	53 MB	-146 B (0%)

_{compressed-size-action}

[codecov]

Codecov Report

Attention: Patch coverage is 53.57143% with 39 lines in your changes missing coverage. Please review.

Project coverage is 52.92%. Comparing base (cf8e715) to head (33b6e95).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/eas-cli/src/project/ios/entitlements.ts	30.77%	9 Missing ⚠️
packages/eas-cli/src/credentials/context.ts	14.29%	6 Missing ⚠️
packages/eas-cli/src/project/expoConfig.ts	76.00%	6 Missing ⚠️
...dUtils/context/DynamicProjectConfigContextField.ts	0.00%	4 Missing ⚠️
...kages/eas-cli/src/credentials/manager/ManageIos.ts	0.00%	3 Missing ⚠️
...ontext/OptionalPrivateProjectConfigContextField.ts	33.34%	2 Missing ⚠️
...dUtils/context/PrivateProjectConfigContextField.ts	33.34%	2 Missing ⚠️
...ackages/eas-cli/src/commands/project/onboarding.ts	33.34%	2 Missing ⚠️
packages/eas-cli/src/project/projectUtils.ts	33.34%	2 Missing ⚠️
.../src/commandUtils/context/ProjectIdContextField.ts	50.00%	1 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2529      +/-   ##
==========================================
- Coverage   52.93%   52.92%   -0.01%     
==========================================
  Files         570      570              
  Lines       21828    21862      +34     
  Branches     4293     4302       +9     
==========================================
+ Hits        11553    11568      +15     
- Misses      10241    10260      +19     
  Partials       34       34              

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

[wschurman]

There are two approaches we could take, I don't have a strong preference:

1. Call the CLI (npx expo config).
2. require these modules in the project (what this PR does).

For expo-updates calls from EAS CLI we chose to use a CLI that returns JSON since it's a bit clearer to reviewers when a change is a breaking change, and as developers we're more attuned to knowing when a CLI change is breaking.

For option 2 to be stable in perpetuity, we need to add some constraint/test/something in the @expo/config package that calls it in the same way that we'd be introducing here in this PR to ensure that the function signature never changes. My recommendation would be an integration test in that package that is essentially the same as the updated expoConfig.ts and entitlements.ts files in this CLI.

I think if we can do option 2 (what this PR does) and add a signature stability API then this PR is good to go, but let's add that stability guarantee to the destination package before landing this to be sure it's doable.

[wschurman]

Just a new piece of info: npx expo config has a --json flag to disable console during execution to prevent broken JSON!

[szdziedzic]

Awesome! I will refactor it to use approach number 1 as in expo-updates then. Thanks @wschurman.

[szdziedzic]

Oh, I see that it can be pretty straightforward for npx expo config however there still is compileModsAsync 🤔 I believe it still needs to be dynamically required, right? 🤔

[github-actions]

Subscribed to pull request

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

Generated by CodeMention

[szdziedzic]

Ok I believe npx config --type introspect should do the job here 🎉

[szdziedzic]

@wschurman Thanks once again for the tips! I'm sorry that it took so long I was off the grid for the last 2 weeks and I've just got back to working normally. Can you please take a look at it again 🙏?

[wschurman]

One inline comment, otherwise LGTM. As far as releasing this goes, we'll definitely want to do some testing of a broad set of commands to ensure it works since almost every command calls it.

[wschurman]

Would also be good to get one more approval on this before landing. Could help to remove some reviewers to better indicate who is responsible for review.

[wschurman]

Narrowing reviewers so hopefully this gets reviewed.

[szdziedzic]

@wschurman I plan to finally merge it today; I run both builds and updates with projects with different SDK versions and raw RN projects.

It all seems to work. The issue that occurred after the previous @expo/config bump no longer occurs.

What do you think about marking a new release as major (even though it probably should be minor because this change should not be breaking) just for extra caution and extra warning for the users? I also plan to let Dev Success know about it so they can help people better if some weird things start to happen.

[szdziedzic]

Ok I figured out that we also need to use EXPO_NO_DOTENV=1 to keep CLI behavior consistent with what was it doing before. It's fixed.

[sjchmiela]

As far as I understand looks good.

[github-actions]

✅ Thank you for adding the changelog entry!

[szdziedzic]

Merge activity

• Nov 5, 1:33 PM EST: A user started a stack merge that includes this pull request via Graphite.
• Nov 5, 1:33 PM EST: A user merged this pull request with Graphite.

[wschurman]

I think the issue might be that this command now does the config for both platforms (https://github.com/expo/expo/blob/main/packages/%40expo/cli/src/config/configAsync.ts#L66-L75) while previously it only did the getPrebuildConfigAsync and compileModsAsync for ios.

[szdziedzic]

Ohh, good catch