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

import defer testing plan #4215

Open
35 of 38 tasks
nicolo-ribaudo opened this issue Sep 2, 2024 · 3 comments
Open
35 of 38 tasks

import defer testing plan #4215

nicolo-ribaudo opened this issue Sep 2, 2024 · 3 comments
Assignees

Comments

@nicolo-ribaudo
Copy link
Member

nicolo-ribaudo commented Sep 2, 2024

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).

Deferred namespace object

  • It is an object
  • It is not the same object as the non-deferred one
  • We should duplicate all the normal namespace object tests
  • 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
  • [[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()
@nicolo-ribaudo nicolo-ribaudo self-assigned this Sep 2, 2024
@ptomato
Copy link
Contributor

ptomato commented Sep 13, 2024

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

@nicolo-ribaudo
Copy link
Member Author

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

@linusg
Copy link
Member

linusg commented Dec 18, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants