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

Scope of built-in module map #64

Open
littledan opened this issue Sep 13, 2020 · 0 comments
Open

Scope of built-in module map #64

littledan opened this issue Sep 13, 2020 · 0 comments

Comments

@littledan
Copy link
Member

In the specification draft, algorithms which deal with built-in modules accept a referrer parameter. I'm trying to understand how this would be controlled in practice. Naively, I was imagining that the built-in module map would instead be referrer-independent and shared Realm-wide.

I don't quite understand how a host would make another kind of scheme work, as the BuiltinModule.export API doesn't give you any particular parameter in its signature to modulate how widely it takes effect. Some random thoughts:

  • Are we anticipating that there will be host-specific APIs similar to BuiltinModule.export which give more explicit scope control?
  • Would the scope be a single module/script by default, and you'd concatenate the built-in module polyfilling to the beginning of each JS file?

In terms of spec mechanics, I see scriptContext frequently referenced when calling these host APIs. If someone could explain what that is supposed to refer to, then that may clear up this question.

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

1 participant