System.import()?

[Jason Orendorff]

On Tue, Aug 18, 2015 at 12:11 PM, Domenic Denicola <d at domenic.me> wrote:
>> HostResolveImportedModule is widely implemented by compilers, though
>> not by browsers. People are writing, using, and sharing ES6 modules today.
>
> So what is your proposal then? Just standardize the node module resolution algorithm, since that is what transpilers are doing?

Here's what I had in mind:

*   Do not standardize the Node algorithm or any other module loading
algorithm in ECMA-262. That responsibility belongs to the Loader
standard.

*   Change the signature of HostResolveImportedModule to match
`System.import()`, which takes a this-value and two strings (name and
referrer).

*   Clarify that HostResolveImportedModule (and its existing callers
in the spec) operate asynchronously, e.g. by adding a
PromiseCapability argument, like PerformPromiseAll. (The async
functions proposal takes a different approach to specifying async
algorithms, but I'm not sure if that's final wording or what exactly.)

*   Specify a `System` builtin object.

*   Specify a builtin method System.import(name[, referrer]) that
performs these steps:

    1.  Let promiseCapability be NewPromiseCapability(%Promise%).

    2.  Return HostResolveImportedModule(this value, name, referrer,
promiseCapability).

Nothing terribly exciting here. Some vaguely interesting refactoring
in the second and third bullet points.

The intent with `System.import()` all along was to provide a dynamic
equivalent to the static `import` syntax. Why not go one step further
and make it official that they share an implementation? That's all
this proposal does, and that's enough to make a useful standard API
for people who are writing ES6 modules right now.

-j