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

Make ns.foo trigger evaluation also for non-existing properties #33

Merged
merged 3 commits into from
Mar 27, 2024

Conversation

nicolo-ribaudo
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo commented Mar 27, 2024

This change solves a few problem:

  1. There was currently no way to trigger evaluation of a deferred module with no exports (see No named exports edge case #19 by @guybedford). I was initially leaning towards just banning import defer * as ns, but the solution in this PR also has the benefit in (2).
  2. When implementing import defer * in tool, it's not always easy to know the list of bindings exported by a module at runtime without evaluating it. Examples are Webpack and Babel, that get the list of exports from properties of an object populated by the module evaluation. It would be possible in some cases to hard-code the list of exports, but it introduces additional complexity and duplicated information in the generated bundle.

Symbols still do not trigger evaluation, because:
a. it's guaranteed that exports of a module have string names
b. module[Symbol.toStringTag] === "Module" can still be used to detect probable namespace objects without forcing their evaluation.

@nicolo-ribaudo nicolo-ribaudo merged commit 9552727 into tc39:main Mar 27, 2024
@nicolo-ribaudo nicolo-ribaudo deleted the eval-on-string-get branch March 27, 2024 16:49
@guybedford
Copy link
Collaborator

I must admit I did prefer the pure model framing in #19 (comment) in making this an error. I understand if detecting the list is tricky in unbound tooling workflows, but I'm not completely sure I agree that justifies omitting the error.

@nicolo-ribaudo
Copy link
Member Author

I will prepare a PR for that — I don't have a super strong preference between these possible behaviours

@Jack-Works
Copy link
Member

but the ecosystem also uses module[__esModule] to interop

@nicolo-ribaudo
Copy link
Member Author

nicolo-ribaudo commented Mar 28, 2024

Since it's a known string it can be easily worked around. For example, the webpack implementation doesn't trigger evaluation on __esModule.

nicolo-ribaudo added a commit to nicolo-ribaudo/proposal-defer-import-eval that referenced this pull request Mar 28, 2024
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

Successfully merging this pull request may close these issues.

3 participants