-
Notifications
You must be signed in to change notification settings - Fork 85
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] warn for misconfigured channel configuration for eas update #1082
base: main
Are you sure you want to change the base?
Conversation
Size Change: +2.44 kB (0%) Total Size: 25.2 MB
|
Codecov Report
@@ Coverage Diff @@
## main #1082 +/- ##
==========================================
- Coverage 51.13% 50.15% -0.98%
==========================================
Files 391 348 -43
Lines 14049 12766 -1283
Branches 2933 2451 -482
==========================================
- Hits 7182 6401 -781
- Misses 6333 6354 +21
+ Partials 534 11 -523
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
@dsokal pointed out to me that I need to account for the possible difference between android and ios configuration, both in the update:configure scenario and the build scenario. Will update the PR for this. |
if ((await checkEASUpdateURLIsSetAsync(exp)) && buildProfile.profile.releaseChannel) { | ||
Log.warn(`» Build profile ${chalk.bold( | ||
buildProfile.profileName | ||
)} in your eas.json specifies the "releaseChannel" property. |
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.
I'd make "releaseChannel"
and "channel"
bold but I don't have a strong opinion on this.
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.
Our pattern is:
- file names should be bold
- a value like the build profile should be in quotes
- if there is a value that goes into code, we use back ticks
if (buildProfiles.length > 0) { | ||
await checkBuildProfileConfigMatchesProjectConfigAsync(projectDir, buildProfiles[0]); | ||
} |
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.
- Apply the suggestion shared on Slack.
- I'd move it to
prepareAndStartBuildAsync
. There's anexp
object available there so you wouldn't need to callgetConfig
incheckBuildProfileConfigMatchesProjectConfigAsync
.
projectDir: string, | ||
buildProfile: ProfileData<'build'> | ||
): Promise<boolean> { | ||
const { exp } = getConfig(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.
IMO this should be passed as an argument.
|
||
export async function checkEASUpdateURLIsSetAsync(exp: ExpoConfig): Promise<boolean> { | ||
const configuredURL = exp.updates?.url; | ||
const projectId = await getProjectIdAsync(exp); |
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.
I'd also pass this as an argument.
projectDir: string | ||
): Promise<boolean> { | ||
const easJson = await new EasJsonReader(projectDir).readAsync(); | ||
if (easJson.build && Object.entries(easJson.build).some(([, value]) => value.releaseChannel)) { |
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.
IMO the second condition is too complicated to keep it inline.
import { Flags } from '@oclif/core'; | ||
import assert from 'assert'; | ||
import chalk from 'chalk'; | ||
import { promises as fs } from 'fs-extra'; |
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.
import { promises as fs } from 'fs-extra'; | |
import fs from 'fs-extra'; |
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.
or import promises
from fs
.
|
||
if (releaseChannelsFound) { | ||
try { | ||
await fs.writeFile( |
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.
Not a strong opinion, but I would prefer to avoid modifying eas.json automatically:
- maybe someone is using both classic and eas updates
- we are forcing formating/indentation level
- users might have their eas.json structured in a specific way that is helpful for readability that we might break here,
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.
- You can't use both at the same time, because the
releaseChannel
andchannel
fields are mutually exclusive - We modify and write app.json as well
- If someone really doesn't like the changes they can decide to rollback the change and not commit it
But most importantly: I think the amount of people missing this migration change in the docs and ending up with updates that don't work outweighs any downsides for the tiny minority who has manually applied some special indentation to the file.
@@ -74,3 +78,60 @@ export function ensureValidVersions(exp: ExpoConfig, platform: RequestedPlatform | |||
throw error; | |||
} | |||
} | |||
|
|||
export async function checkDeprecatedChannelConfigurationAsync( |
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.
you are mixing here to responsibilities, this function should either:
- check if current config is deprecated and return true/false without logging anything. I would also expect in that case that function will be named
isUsingDeprcatedChannelCOnfiguration
or sth like that - handle the situation(e.g. print warning and return) and do not return any values
return false; | ||
} | ||
|
||
export async function checkBuildProfileConfigMatchesProjectConfigAsync( |
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.
The same as above, it should either handle the situation or return boolean(not both)
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 still some comments to address, but overall I think this is the right direction and will help people migrate from classic to EAS Update. Thanks for taking this on!
if (value.releaseChannel) { | ||
releaseChannelsFound = true; | ||
easJson.build[key].channel = value.releaseChannel; | ||
delete easJson.build[key].releaseChannel; |
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.
Can we log that we changed this?
Log.withTick(`Migrated the Classic Updates release channel "${value.releaseChannel}" to be an EAS Update channel.`)
if ((await checkEASUpdateURLIsSetAsync(exp)) && buildProfile.profile.releaseChannel) { | ||
Log.warn(`» Build profile ${chalk.bold( | ||
buildProfile.profileName | ||
)} in your eas.json specifies the "releaseChannel" property. |
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.
Our pattern is:
- file names should be bold
- a value like the build profile should be in quotes
- if there is a value that goes into code, we use back ticks
@kbrandwijk is this PR something we still want to merge? If no can we close it? |
I still like to have this feature, but I don't have the bandwidth currently to address that main comment you left on it. |
Checklist
/changelog-entry [breaking-change|new-feature|bug-fix|chore] [message]
and CHANGELOG.md will be updated automatically.Why
One of the most common issues with EAS Update is that users still have
releaseChannel
in theireas.json
instead ofchannel
. This PR tries to make the user aware of this in three cases.How
When running
eas update:configure
, the CLI will now automatically migrate thereleaseChannel
property tochannel
for all build profiles.When running
eas update
, the CLI will warn if any build profiles are still using thereleaseChannel
property.When running
eas build
, the CLI will warn only if both the project is configured to use EAS Update and the selected build profile has thereleaseChannel
property.In that last case, I'm on the fence if the CLI should show and error and abort instead of just warn for interactive builds.
Test Plan
Tested the various use cases manually. There's not many test cases at the points where the changes were made, I can improve on that in a separate PR.