fix(defer): evaluate async dependencies where the deferred import sits - #21902

Summary

A deferred import's async transitive dependencies were only started when the importing module awaited its dependencies, so every synchronous sibling ran first. With import defer * as ns2 from "./dep-2.js" sitting between two plain imports:

before: 1, 3, 5, │ 2.1.1 start, 2.2.1, 2.2 start │ 2.1.1 end, …
after:  1, │ 2.1.1 start, 2.2.1, 2.2 start │ 3, 5, 2.1.1 end, …

The emitted code was already in source order — makeOptimizedDeferredNamespaceObject recorded the ids and deferredModuleAsyncTransitiveDependencies first required them from handleDependencies. Three things had to change together:

• They now start at the import. GatherAsynchronousTransitiveDependencies skips a module whose status is evaluating or evaluated, so a deferred import that cycles back to the module currently evaluating contributes nothing and cannot deadlock. That guard is applied where the list is built, which is the only place the two cases are distinguishable.
• The "already finished" check had no effect. It read webpackDone from the module record, but that flag is only ever set on the promise in module.exports, so it silently reduced to "never required". That was equivalent while nothing started these early; it is not once the import does.
• Gathering walks the imports in source order. getOutgoingAsyncModules iterated the outgoing-connections map, whose order is not the source order the spec reads from [[RequestedModules]] — matching in development and diverging under production ids.

Un-skips test262's import-defer/evaluation-top-level-await/flattening-order.

What kind of change does this PR introduce?

fix

Did you add tests for your changes?

Yes — configCases/defer-import/async-transitive-evaluation-order, which asserts the async dependency starts before the sibling below the deferred import and that the deferred module's own body still waits for the namespace. Verified failing on unmodified lib/ and passing with the change, in both the plain and filesystem-cache suites. test262 import-defer|top-level-await|dynamic-import is 4022 passing with none failing, and the full test:basic run is clean apart from the sandbox-only failures the contributing guide names.

Does this PR introduce a breaking change?

No. The same modules are evaluated eagerly as before — only the point at which they start moves, and only for a graph reached through import defer.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

n/a

Use of AI

AI (Claude Code) was used throughout: to reproduce the divergence as a standalone bundle, read the emitted runtime to locate where the dependencies were first required, and write the fix and the config case. Two intermediate attempts were rejected on evidence — starting the dependencies alone left the importer no longer awaiting them, and guarding the cycle at await time could not tell a cycle apart from a dependency the import had just started, which regressed get-other-while-evaluating-async. All findings and reasoning were reviewed by me before committing.

Generated by Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved deferred import evaluation so asynchronous dependencies execute in source order.
  • Ensured deferred module bodies evaluate only when their namespace is accessed.
  • Prevented already-running asynchronous dependencies from being evaluated again.
  • Propagated asynchronous dependency errors consistently to all affected deferred imports.

• Tests

  • Added coverage for asynchronous evaluation order, dependency failures, and top-level await.
  • Enabled a previously skipped standards test now that evaluation ordering behaves correctly.