Repository navigation
dynamic import() no longer seeds AsyncLocalStorage on globalThis - #13890
Merged
Merged
Conversation
…torage The entry seeds globalThis.AsyncLocalStorage only when the Next.js path-init list is non-empty, and that list also took every module whose init kind is Deferred, i.e. every module reached only through import(). So any program with a dynamic import got an AsyncLocalStorage global that node does not have. The list now holds modules by where they are (.next/server/** and compilePackages directories), as its seed rule assumes. A deferred module keeps its path anchor through the lazy registrar, exactly like an on-demand CommonJS module: an import() site calls its target's init directly, and only a program that can require by path (not closed) looks the address up, at its first path lookup.
|
Caution Review failedThe pull request is closed.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. CodeRabbit Verify
|
Contributor
Author
|
Ready on local verification: CI cannot run right now (setup-llvm22's wget of the apt.llvm.org key exits 4 on GitHub runners since ~14:10Z, every branch). Local on qb9: new gap test fails on main and passes here; all 27 gap tests using import() match node; codegen entry tests; startup irdiff six witnesses exact 0; nextjs-hello compiled with this head matches main and node on all 5 routes. Lint gates: same 17 failures as main, nothing new. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
fix(compile): dynamic import() no longer seeds globalThis.AsyncLocalStorage
Cause
crates/perry-codegen/src/codegen/entry.rsseedsglobalThis.AsyncLocalStoragebefore module init when theentry's Next.js path-init list (
nextjs_path_init_modules) is non-empty. That rule treats the list as"this is a Next.js program". Since #7312,
run_pipeline.rsalso put every module withModuleInitKind::Deferred(every module reached only throughimport()) on that list. So any programwith a dynamic import got an
AsyncLocalStorageglobal that node does not have:Fix
The list holds modules by where they are (
.next/server/**, compilePackages directories), as the seed ruleassumes. A deferred module still gets its path anchor, now from the lazy registrar
(
js_register_path_inits_lazily), just like an on-demand CommonJS module. Animport()site calls itstarget's
__initdirectly. Only a program that is not closed can look a module up by path, and the lazyregistrar registers the anchors on the first lookup. No new flag and no new list.
Receipts (qb9, head vs main e8eb6bf)
function, head printsundefined, matching node.test_gap_als_seed_dynamic_import.ts: fails on main, passes on head.import(, the dynamic_import tests and the newtest). Head matches node on 27/27, main on 26/27. The only difference is the new test.
.next/server/x.jsmodule, imported statically or dynamically, still gets the seed on head (function, same as main).cargo test -p perry-codegen --lib codegen::entry: 33 passed. These include the Next dylib seed and path-registration tests.cargo test -p perry --bin perry commands::compile: 1051 passed, 1 failed. The failing test,fs_promises_named_glob_in_class_enables_regex_engine, fails the same way on main source.scripts/a1/irdiff.sh, six witnesses (hello, commander_help, commander, fastify_inject,awfy_richards, binary_trees): delta 0 Ir and 0 functions with +Ir on every witness.
.textand filebytes are identical, and linkpad converged.
tests/test_next_app_route_dylib.shdoes not reach the route on qb9 for head or main: both stop atnode:http has no providerunder the script'sPERRY_DISABLE_WELL_KNOWN=1. This is not caused by this change.