Add requirements for ESM-supporting runtimes #49
Conversation
This also includes specifying `import.meta.main` and allowing runtimes to customize module loading. Closes wintercg#46.
|
@nicolo-ribaudo PTAL at the usage of the HTML spec import machinery One big TODO is how to define |
| [=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]].) |
There was a problem hiding this comment.
Where can this perform the fetch hook be obtained from? Somewhere globally available, or can it be potentially different per module?
There was a problem hiding this comment.
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]]. |
There was a problem hiding this comment.
This prevents runtimes from supporting other attributes, rather than just making sure that they support type. Is it intended?
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
If a runtime never has entry points, is there any observable difference between the HTML algorithm and the one below?
There was a problem hiding this comment.
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> } ». |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This also includes specifying
import.meta.mainand allowing runtimes to customize module loading.Closes #46.