-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[eas-cli] use expo config related functions shipped with project's expo package to resolve config #2529
base: main
Are you sure you want to change the base?
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @szdziedzic and the rest of your teammates on Graphite |
Size Change: -1.57 kB (0%) Total Size: 52.9 MB
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two approaches we could take, I don't have a strong preference:
- Call the CLI (
npx expo config
). 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.
Just a new piece of info: |
Awesome! I will refactor it to use approach number 1 as in |
Oh, I see that it can be pretty straightforward for |
82304e9
to
016c941
Compare
b5f49ac
to
9cd41f7
Compare
|
Ok I believe |
@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 🙏? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
['expo', 'config', '--json', ...(opts.isPublicConfig ? ['--type', 'public'] : [])], | ||
|
||
{ | ||
cwd: projectDir, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to pass env
into spawnAsync? (we do for the expo-updates CLI). Or does the process.env override on L52 work?
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. |
016c941
to
2dbaed5
Compare
0dd8947
to
da4d277
Compare
da4d277
to
8536a7a
Compare
❌ It looks like a changelog entry is missing for this PR. Add it manually to CHANGELOG.md. |
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 thatgetConfig
,getPrebuildConfig
, andcompileModsAsync
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
, andcompileModsAsync
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.