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

Add requirements for ESM-supporting runtimes #49

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

andreubotella
Copy link
Member

This also includes specifying import.meta.main and allowing runtimes to customize module loading.

Closes #46.

This also includes specifying `import.meta.main` and allowing runtimes
to customize module loading.

Closes wintercg#46.
@andreubotella
Copy link
Member Author

@nicolo-ribaudo PTAL at the usage of the HTML spec import machinery

One big TODO is how to define import.meta.main in a way that excludes browsers – or do we even want that?

Copy link

@nicolo-ribaudo nicolo-ribaudo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review since I have been pinged

[=Web-interoperable runtimes=] which support EcmaScript modules must implement the following ECMA-262 host hooks as follows:

: [$HostLoadImportedModule$]
:: This host hook must be implemented [[HTML#hostloadimportedmodule|as defined in the HTML spec]], except that they may pass a [=perform the fetch hook=] algorithm to [=fetch a single imported module script=] even when <var ignore="">loadState</var> is undefined. (See also [[#custom-module-loading]].)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where can this perform the fetch hook be obtained from? Somewhere globally available, or can it be potentially different per module?

Copy link
Member Author

@andreubotella andreubotella Jul 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention was to have a single "perform the fetch hook" algorithm per runtime, if that runtime needs or supports module loading customizations. But the intention was also for this spec change to be generic enough that it could cover npm imports and Node.js's custom loaders, but now that I look into it, even a per-module hook isn't enough for that because it doesn't override module resolution. I will think of other ways to make these customizations possible.

: [$HostLoadImportedModule$]
:: This host hook must be implemented [[HTML#hostloadimportedmodule|as defined in the HTML spec]], except that they may pass a [=perform the fetch hook=] algorithm to [=fetch a single imported module script=] even when <var ignore="">loadState</var> is undefined. (See also [[#custom-module-loading]].)
: [$HostGetSupportedImportAttributes$]
:: This host hook must be implemented [[HTML#hostgetsupportedimportattributes|as defined in the HTML spec]].

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This prevents runtimes from supporting other attributes, rather than just making sure that they support type. Is it intended?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was not intended, but the rest of HTML import algorithms don't support any attributes other than type, and the attributes are not passed to the perform the fetch hook, so there's no way to customize the import any further based on the attributes. Again, I will try to think of other ways to enable this.

: [$HostGetSupportedImportAttributes$]
:: This host hook must be implemented [[HTML#hostgetsupportedimportattributes|as defined in the HTML spec]].
: [$HostGetImportMetaProperties$]
:: If a runtime can never have an [=entrypoint module=] for any [=agent clusters=] (e.g. web browsers), then it may implement this host hook [[HTML#hostgetimportmetaproperties|as defined in the HTML spec]]. Otherwise, it must implement it as follows:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a runtime never has entry points, is there any observable difference between the HTML algorithm and the one below?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the algorithm below, import.meta.main will exist and be set to false for non-entrypoint modules, whereas with the HTML algorithm import.meta.main does not exist.

1. Let <var>moduleScript</var> be <var ignore="">moduleRecord</var>.\[[HostDefined]].
1. Let <var>urlString</var> and <var>resolveFunction</var> be [[HTML#hostgetimportmetaproperties|as defined in the HTML spec]].
1. Let <var>is main</var> be true if <var>moduleScript</var> is the [=surrounding agent=]'s [=agent cluster=]'s [=entrypoint module=]; false otherwise.
1. Return « [=Record=] { \[[Key]]: "<code>url</code>", \[[Value]]: <var>urlString</var> }, [=Record=] { \[[Key]]: "<code>resolve</code>", \[[Value]]: <var>resolveFunction</var> }, [=Record=] { \[[Key]]: "<code>main</code>", \[[Value]]: <var>is main</var> } ».
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to define more strictly what the resolveFunction implementation should look like? Like how many arguments does it take, and what its return value should look like. Asking because I think Node.js would like to have an optional second parameter to allow access to the resolve value from another module's perspective. Also it'd be convenient for us if the return value could be a URL instance.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See nodejs/modules#550 and whatwg/html#5572. Node has been engaging with WHATWG for years on this, and at this point I think we’ve accepted that we’re following whatever signature is allowed by the HTML spec. I would be nervous if WinterCG approved an API that differed from HTML’s.

We could perhaps introduce some new API, import.meta.resolveURL say, for a different variation.

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.

Add import.meta
6 participants