import defer testing plan

[nicolo-ribaudo]

https://github.com/tc39/proposal-defer-import-eval/

Syntax

Valid cases

import defer * as ns from "mod";

import defer from "mod";

import defer * as ns from "mod";
export { ns };

Invalid cases (one per file)

import defer x from "mod";
import defer { x } from "mod";
import defer y, * as ns from "mod";
import defer as ns from "mod";
export defer * as ns from "mod";

• All the existing dynamic import syntax tests should be duplicated to import.defer (both valid and invalid) (Add syntax tests for import.defer #4374)

Deferred namespace object

• It is an object
• It is not the same object as the non-deferred one
• Importing twice gives the same object
  • static/static
  • static/dynamic
  • dynamic/dynamic
  • static from different files
• import and import defer + exec only execute the module once
• @@toStringTag (Add test for @@toStringTag on deferred module namespaces #4360)

Evaluation

Sync

• import defer does not trigger evaluation
• import.defer does not trigger evaluation (Add evaluation tests for import.defer with sync/async modules #4375)
• [[Get]] triggers evaluation
  • with a known export name
  • with a non-exported name
  • does not trigger evaluation with a symbol
• What operations trigger evaluation (Update import defer tests for evaluation triggers #4341)

Errors

• Property access re-throws the evaluation error
  • On first access for not evaluated modules
  • On second access for not evaluated modules
  • On first access for already evaluated modules
• Import defer of an errored module doesn't throw
• ReadyForSyncExecution
  • Cannot evaluate a module in its evaluating state
  • Cannot evaluate itself
  • Cannot evaluate a module with a dependency in an evaluating state
  • The error when evaluating a module with two dependencies, where the first one is linked and the second one is evaluating, happens before evaluating the first one
  • A deferred module evaluates itself while being deferred-evaluated
  • Cannot evaluate a module in its evaluating-async state
  • Cannot evaluate itself after a TLA
  • Cannot evaluate a module with a dependency in an evaluating-async state.
• Syntax error are not deferred
• Linking errors are not deferred

Async

• Async modules are not deferred
• Sync modules with async dep are deferred, but their async deps are not
• Sync deps of async modules are not deferred
• Async transitive deps are flattened and exexuted in the right order
• All these tests also for dynamic import.defer() (Add evaluation tests for import.defer with sync/async modules #4375)

[ptomato]

@nicolo-ribaudo Can you suggest someone from whom it would be useful to get feedback on this testing plan?

[nicolo-ribaudo]

Maybe @takikawa who's working on an implementation, or @guybedford.

[linusg]

Under "valid cases" you list this example:

import defer from "mod";

Just to clarify - that's still a regular import of an export default creating a binding named defer and not actually changed by this proposal, right?

[nicolo-ribaudo]

Yes, the test is checking that the behavior is the same as it was in ES2015, and that implementations don't accidentally mess up parsing.