Modules feedback from March 2013 meeting

James Burke jrburke at
Mon Mar 25 21:18:40 PDT 2013

Hi Sam,

I really was not expecting a reply, as it was a lot of feedback. Just
wanted to get some things in the "to be considered at some point/use
case" queue. Some clarifications, but I do not think it is worth
continuing discussion here given the breadth of the feedback and the
stage of the spec development:

On Mon, Mar 25, 2013 at 12:56 PM, Sam Tobin-Hochstadt <samth at> wrote:
>> With that capability, it may be possible to go without `import` at
>> all, at least at this stage of ES (macros later may require it). The
>> one case where I think `import` may help are cycles, but if the cycle
>> parts are placed in separate modules with a single export, it may
>> still work out. Using the assumption of single anonymous export and
>> the "odd even" example from the doku wiki:
> Therefore, these changes aren't really simplifying things.

Does it complicate things more though? While import checking may not
change much, hopefully the simplifications are:

* removal of an import syntax keyword (just have `from`)
* possibly reducing the scope of export syntax
* possible improvement in general destructuring, even when a module is
not the target.

Maybe this makes some things much more complicated. If so, it would be
good to document why/include in the use cases at some point.

I believe this is at the heart of some of the "this seems complicated"
feedback, but hopefully expressed in a more precise, targeted way as
to what needs to be explained to someone who might think that. It does
not need to be explained now, just calling out a candidate for the
documentation/use case queue.

>> ### Loader pipeline hooks ###
> The system doesn't build AMD-style plugins into the core of the module
> proposal, however. They're neither fully-general (you could configure
> based on something other than a prefix) nor used everywhere in
> existing JS, and we don't want to prematurely standardize on one
> system.

AMD-style plugins would purposely not be fully general in this system,
that is the job of the loader pipeline hooks.

It does not have to be AMD-style directly, but something where I could
specify a module ID that could handle a type of resource ID, that
module gets loaded (with its dependencies), and it gets automatically
wired into the pipeline if it exposes a property whose name matches a
pipeline hook name.

This is also why I suggest more declarative config, like shim vs an
imperative link hook. It is still useful to have the loader hooks as
they are, but just like "ondemand" is being considered, there are
others that have been proven useful without prone-to-error imperative
overrides of hooks (don't forget to check for a previous one and call
it (before, after?) you run your code).

Since the loader pipeline stuff is still under development though,
this feedback may be much to early.

>> ### Nested modules ###
> You could express this as:
>  module "publicThing/j" {}
>  module "publicThing/k" {}
>  module "publicThing" {
>    export …. //something visible outside publicThing
>  }

I am sorry, I mixed how the code would be on disk with how it may be
organized later conceptually after loading. How the example would be
on disk:

//In publicThing.js
module "j" {}
module "k" {}
export …. //something visible outside this module

Then, this module is imported by some other module via the
"publicThing" name. So, publicThing.js does not know its final ID, and
"j" and "k" are not meant to be exposed as public modules, they are
just for publicThing's internal use.

The ID lookup tables I visualized more like the "maps with prototypes"
with the prototype being a parent module space map.  Unfortunately we
probably do not share a common vocabulary here, so I will stop trying
to suggest a solution and just point out the use case.

>> ### Legacy opt-in use case ###
>> //Some base library that needs to be in ES5 syntax:
>> var dep1, dep2
>> if (typeof System !== 'undefined' && System.get) {
>>     //ES6 module loader. The loader will fetch and process
>>     //these dependencies before executing this file
>>     dep1 = System.get('dep1');
>>     dep2 = System.get('dep2');
>> } else {
>>     //browser globals case, assume the scripts have already loaded
>>     dep1 = global.dep1;
>>     dep2 = global.dep2;
>> }
> In this setting, you could just run the code exactly as you wrote it,
> without changing the default loader at all, and it would work provided
> that the dependencies were, in fact, already loaded, just the way it's
> assumed in the browser globals case.  I imagine that lots of libraries
> will work exactly like this, the same way jQuery plugins expect jQuery
> to already be loaded today.

We have found in the AMD world that once the developer has a module
loader API, they want to avoid loading scripts in some manually
constructed order specified outside of JS, in HTML. If the user needs
a third party script loader to do this on top of ES modules, that
seems redundant.

> Adding a build step that performs this analysis explicitly seems like
> a much better idea than building an ad-hoc analysis that changes the
> semantics of these methods.

I may be misunderstanding "ad-hoc analysis", but I am only suggesting
looking for `System.get("StringLiteral")` just as the system looks for
`from "StringLiteral"`. Specifically, the analysis should not be
expanded to node/commonjs/amd APIs.

I am not sure what what semantics you reference will change. If you
mean things like "script may not be executed like it is when loaded
via an HTML script tag", library authors have adapted, some patterns
are here:

So library authors are already used to "this module system is in play,
the global could be different, I need to behave differently in this
way if this module system is available". Getting wider use of their
library in other systems is usually worth doing the change for them.
That, or letting people know what kind of declarative "shim config"
works for it. However, changing their lib to use ES6 syntax is likely
not an option for a couple years.


More information about the es-discuss mailing list