Skip to content
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

fastboot chunk preloading fix #1109

Merged
merged 1 commit into from Feb 5, 2022
Merged

fastboot chunk preloading fix #1109

merged 1 commit into from Feb 5, 2022

Conversation

ef4
Copy link
Contributor

@ef4 ef4 commented Feb 5, 2022

Ember Fastboot is deliberately designed to be able to run the same build output that was produced for the browser in Node, without an entire second build for this second environment.

In order to fit in with that architecture, Embroider preloads all lazy chunks in fastboot, so that we never hit webpack's runtime loader (which will expect to be running in the browser and break in fastboot).

Previously, the way we identified the lazy chunks was simply by listing all the chunks and seeing which ones were not used as entry chunks for any entrypoint. But this was incorrect.

A chunk could be used lazily by one entrypoint (like the app) while being used eagerly by another (like the test suite). In this case we would miss preloading it and get a runtime error.

This changes the chunk categorization strategy to track the lazy chunks per-entrypoint.

Ember Fastboot is deliberately designed to be able to run the same build output that was produced for the browser in Node, without an entire second build for this second environment.

In order to fit in with that architecture, Embroider preloads all lazy chunks in fastboot, so that we never hit webpack's runtime loader (which will expect to be running in the browser and break in fastboot).

Previously, the way we identified the lazy chunks was simply by listing all the chunks and seeing which ones were not used as entry chunks for any entrypoint. But this was incorrect.

A chunk could be used *lazily* by one entrypoint (like the app) while being used *eagerly* by another (like the test suite). In this case we would miss preloading it and get a runtime error.

This changes the chunk categorization strategy to track the lazy chunks per-entrypoint.
output.lazyBundles.set(
id,
chunks
.filter(chunk => chunk.runtime?.includes(id) && !entrypointAssets?.find(a => a.name === chunk.files?.[0]))
Copy link
Contributor Author

@ef4 ef4 Feb 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find any obvious docs about chunk.runtime but it appears to mean what we need it to mean: which entrypoints can use this chunk at runtime.

@ef4 ef4 merged commit cfa8c51 into main Feb 5, 2022
@ef4 ef4 deleted the fastboot-bugfix branch February 5, 2022 18:43
@ef4
Copy link
Contributor Author

ef4 commented Feb 5, 2022

@krisselden I think this might be the fix to the problem you were having with fastboot dying on document is undefined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants