Discuss
  • Modules: use of non-module code as a dependency

Modules: use of non-module code as a dependency

# James Burke (13 years ago)

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

# David Herman (13 years ago)

On Jun 30, 2012, at 11:06 AM, James Burke wrote:

Possible answers:

  1. Unsupported. Error occurs.

  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'm curious why you didn't include what seems like the most straightforward answer to me: jQuery continues to work as it did before, and just like always, you include it via a script tag and subsequently access it as a global:

<script src="jquery.js"></script> <script> ... $('#foo').blah().blah() ... </script>

I'm wondering why you didn't include this option -- is it just because jQuery is a special case that creates globals, whereas you also want this to work for modules that don't create globals?

# Aymeric Vitte (13 years ago)

I think I have already raised 10 times at least the fact that the current module proposal does not allow to load a non module so both are complementary and can interact between each others.

<script ..> is not available in non browsers environments

and 3) is unnecesary complicate

Le 30/06/2012 20:19, David Herman a écrit :

# James Burke (13 years ago)

On Sat, Jun 30, 2012 at 11:19 AM, David Herman <dherman at mozilla.com> wrote:

I'm curious why you didn't include what seems like the most straightforward answer to me: jQuery continues to work as it did before, and just like always, you include it via a script tag and subsequently access it as a global:

<script src="jquery.js"></script> <script> ... $('#foo').blah().blah() ... </script>

I'm wondering why you didn't include this option -- is it just because jQuery is a special case that creates globals, whereas you also want this to work for modules that don't create globals?

This is not just because it is jQuery, it is just for any baser libraries a user may use that cannot update to new keyword syntax. One of the options above was that jQuery could do a runtime check for a Loader API like System.set(), but not do the new keywords.

One of the problems a module system should solve is automatic dependency resolution. It should not require a developer to manually map out the dependency tree and load some of them in another loader system (plain script tags in this case) before using them. The harmony module system will look bad, particularly since this is not an issue with existing JS module systems.

James

# Azer Koçulu (13 years ago)
  1. being able to bind variables/object paths to virtual package names. this is what OneJS (azer/onejs) provides to its users and it's being used for documenting and optimizing the code.
# Azer Koçulu (13 years ago)

Here is an example of what I recommended;

package jquery ties window.jQuery