Feed back and proposal for modules: allow importing ES5 files

Alex Russell alex at dojotoolkit.org
Mon Sep 24 03:29:09 PDT 2012

Hi Shaofei:

On Sep 22, 2012, at 6:29 PM, 程劭非 <csf178 at gmail.com> wrote:

> Hi, everyone,
> I noticed that current importing grammar will not work for ES5 files,
> I mean there is no way to import one or more es5/es3 files as a module
> and import variables from it.
> The problem is:
> 1. There are no "export" keywords in a es5/es3 file, no variables are exported.
> 2. They might be using more than one files but current mudule grammar
> allows only one file as one module.
> When the new standard(es6) comes out, I guess a big number of
> libraries need updating. And before they finish their work, I think we
> need a cheap solution for the new code(es6) to use old
> libraries(es5/es3) without modifying their code

One option here is for you to create an export "wrapper" for them, in essence a separate file that requires the old library be loaded which then exports the library's symbols through an export. Not pretty, but it requires no code changes for well-designed libraries.

> For the two points, I was considering two solution:
> 1. Export all global variable by default.
> Anonymous function could be used to protect the global namespace and
> most libraries are already using it. So I don't think "export" is
> needed.

You inadvertently identified why we need "exports": it's very difficult what is "global". In particular, what should be exported in the case of a file that includes:

var f = function(param) {
  thinger = param;

// ...

if (someGlobalConfigurationSetting) {


> Exporting all global variable will not pollute the module's user's
> namespace for we still need "import" phase.

Perhaps instead of "global" you mean "the top-level IFFE"?

In that case, it's easier, but then it depends on the IFFE both being executed (it's not a static form here) and there being only one. Or is the suggestion that a file like this should export both a and b? And what will the value of c be?

// example.js

 var a = p;

 var b = p;

var setValue = function(p){
  var c = p;

setValue("it's a sunny day!");
setValue("it's raining in London");

// end example.js

As you can see, at the limit, this creates some serious hazards for violating the data-hiding provided by closure-bound variables. Suddenly importers can not only see these internal names, but watch their values change!

> 2. Allow importing multiple files as one module.
> This will completely decouple file and module. We need to modify the
> ModuleSpecifier grammar:
> ModuleSpecifier ::= StringLiteral | Path
> ===>
> ModuleSpecifier ::= ( StringLiteral | Path ) ( "," StringLiteral | Path )*
> With this, for example, if I'm using a RSA library like
> <http://www-cs-students.stanford.edu/~tjw/jsbn/>, I can do the
> following:
> import "jsbn.js","prng4.js","rng.js","rsa.js" as RSA;
> If I want to use a module depend on jQuery1.3.2, I can do:
> import "jQuery1.3.2.js","MyModule.js" as MyModule;
> I've mentioned this idea in a reply, post it as a separate thread to
> get more feed back :-)

This is interesting. Do you have a proposed resolution mechanism for conflicts? We had such a thing in the old traits system for classes, but I don't think it has survived anywhere.

Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

More information about the es-discuss mailing list