[pull] canary from vercel:canary #100
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR introduces some extra tracking which makes us treat `import(...)` like a call to a cached function. Thanks to this, `await import(...)` will no longer cause dynamicity errors in `dynamicIO`. The motivation is the same as allowing `fs.readFileSync` -- if something is available on the server at prerender time, we don't consider it IO. Fixes #72589 Closes #75132 ### Implementation notes The tracking is implemented via an SWC transform (`track_dynamic_imports.ts`) that turns `import(...)` into `trackDynamicImport(import(...))`. `trackDynamicImport(promise)` tracks the promise globally, without using `workUnitStore.cacheSignal`. The prospective render subscribes to pending modules using `trackPendingModules(cacheSignal)`, which causes the prospective render to wait for all `import()`s to finish before proceeding to the final render. The mechanism is analogous to `'use cache'`, but the "result" of an `import()` is stored *in the module cache* instead; when we invoke the `import()` again in the actual prerender, it will resolve at microtask-speed, like we need it to. The transform is enabled for all modules that run server-side, both RSC and SSR, because the prerender runs both. This also includes route handlers, because we also use a `cacheSignal` when prerendering those. Notably, we also instrument `import()` in `node_modules` to account for libraries that do lazy initialization. I've also had to adjust the prospective client render in PPR mode to wait for `cacheSignal.cacheReady()` - otherwise, it wouldn't wait for `import()`s to resolve before doing the final client render, which'd subsequently cause a dynamicity error. (we didn't need to wait for `cacheSignal` before, because all cached promises would've already been awaited in the server prerender) Finally, we no longer need `warmFlightResponse`, because `trackPendingModules` already makes the `cacheSignal` wait for all loading chunks to finish, so we don't need to do it ahead of time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )