Modules: use of non-module code as a dependency

[James Burke]

A good chunk of my previous feedback is based on a higher level design
goal that is worth getting a common understanding on, since it may
invalidate my feedback:

Question:

What happens when a module depends on a non-module code?

Example:

I have an ES module, 'foo', it depends on jQuery. foo uses the new
module keywords, but jQuery does not. jQuery could be doing one of two
things:

a) Nothing, just exports a global.
b) May be modified to call the ES Loader's runtime API, something like
System.set().

Code for module foo:

    import jQuery from 'jquery.js'

Possible answers:

1) Unsupported. Error occurs. Developer needs to use a custom loader
that could somehow get jQuery loaded before foo is parsed. Or just
tell the user to stick with existing module schemes until ES module
support has saturated the market.

2) jQuery is suggested to provide a jquery.es.js file that uses the
new keywords.

3) Proposed: When jquery.js is compiled, and no import/module/export
modules are found, then the Loader will execute jquery.js to see if it
exports a value via a runtime API. It uses that value to then finish
wiring up the local jQuery reference for module foo.

I believe #1 will complicate ES module adoption. #2 feels like "there
are now two javascript languages, make your choice on what line you
are on". I'm not sure if #3 could be supported with the current module
design.

James