-
Notifications
You must be signed in to change notification settings - Fork 477
[expo-cli] add --experimental-bundle flag to 'export' command #3074
Conversation
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.
Thanks, this looks good! Left a few comments/questions below.
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 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.
- if this is supposed to be part of EAS, it should maybe be in EAS?
- if this shares a majority of features with export, then it should share code too.
- I'm not sure why we need two CLI commands for generating the static output of a project, this should really be consolidated.
- we want to limit the amount of commands in the expo-cli since there are already a ton and the
--help
prompt is too large.
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 agree with @EvanBacon that we should hide this from --help
for now. we may want to consolidate expo export
into this command and put it behind a flag (or the other way around), ping me on slack and we can chat about that more
There is a big push to seperate the bundler from EAS. @fson, @ide, and @ccheever have suggested going even further in the future and allowing arbitrary bundlers (not included in
Agreed. I made sure to reuse the relevant code from
I initially started writing this as a flag for Note: "hosting an update from a static server" is different from "generating the static output": Hosting on a static server means we create the manifest as well as the bundles and that the client's plist looks for the manifest along a different route Creating just the Combining these commands is possible, but because the output is rather different it seems confusing for the user and from the maintenance perspective the code becomes littered with if/else statements. |
cool, pinged you on slack! |
): Promise<void> { | ||
const absoluteOutputDir = path.resolve(process.cwd(), outputDir); |
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.
This used to be called right before ExportAppAsync
. I brought it inside and replaced the relevant outputDir
with absoluteOutputDir
.
@@ -1586,7 +1651,7 @@ export async function startReactNativeServerAsync({ | |||
_logPackagerOutput(projectRoot, 'error', data); | |||
} | |||
}); | |||
const exitPromise = new Promise((resolve, reject) => { | |||
const exitPromise = new Promise<void>((resolve, reject) => { |
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.
(Unrelated typescript error that I tacked onto this PR)
packages/xdl/src/Project.ts
Outdated
}, | ||
}; | ||
// Skip the hooks and manifest creation if building for EAS. | ||
if (!eas) { |
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.
Everything in this if
statement is copied over from before. Because if (options.dumpSourcemap)
got shifted above the "hooks" block it looks like more change than it is.
@EvanBacon @brentvatne changed from a new command to a flag! |
The flag name looks fine for a temporary option but ideally the exported format would be largely compatible with any host. old: new: |
Good point, talking with @jonsamp about this a bit and maybe |
tbh I think the right path is to work towards making it the default to export the EAS-compatible update format. The old format just needs to stick around to not break existing workflows. Don't need to get there right away but the new format works for all conformant hosts - EAS and otherwise - so there eventually won't be a need for old "expo export" behavior except for compat reasons. |
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.
looks good but at least add a test plan to the PR description
Co-authored-by: Ville Immonen <ville.immonen@iki.fi>
Co-authored-by: Ville Immonen <ville.immonen@iki.fi>
527c5df
to
f6f90e1
Compare
For EAS, we are separating the creation of the bundles from their publication.
expo export
does a lot of other stuff with the assumption that the user will be hosting a personal, non-EAS, static manifest and asset server.expo export --eas
strips away all of the extraneous work inexpo export
and introduces a standardized format to save bundles in for preparation use byeas publish
.Where
metadata.json
has type:This allows for easy expansion of the bundlers we support (which is the key reason for the separation of the bundling and the publishing). The versioning allows us to accommodate dramatic format changes.
Test Plan:
run:
expo export --experimental-bundle
and confirm it creates the new file structure.expo export --public-url test.com
and confirm it creates the old file structure.