moduleloader / es-module-loader Goto Github PK

Currently not implemented in master

I tried the traceur demo, but it blows up the debugger if you have workspace mappings.
https://code.google.com/p/chromium/issues/detail?id=311733

Currently, the js extension is treated like a URL, just like RequireJS.

I believe the module loader will be taking a simpler route by always adding the js extension, whenever the module name is not a URL.

A summary of the resolution rules here: https://gist.github.com/guybedford/3712492cf0f629eed761

This looks way out of date to me. Should it be deleted?

As per the readme, the ES6 Esprima Harmony parser is being used to do parsing, loaded only when necessary. This parser still uses an older syntax, which is currently the major critical issue to sort out for this polyfill.

@guybedford suggested that we explore alternatives and I agree.

Currently this is a limitation of the normalization.

Looks like this is something that used to be in the spec, but disappeared in the last revision.

I just made a suggestion at https://gist.github.com/wycats/51c96e3adcdb3a68cbc3/#comment-888228 for a configure() method, but pending any answer on configuration that works across all import calls, I was wondering whether anyone knew whether the import method's referer argument is intended to be usable for containing configuration properties beyond the "name" and "address" ones?

See jorendorff/js-loaders#25

This system will replace System.ondemand.

Should get this integrated as soon as there is further feedback from the spec side.

I've been considering how to go about polyfilling ES6 functionality dynamically (classes, etc) with this module, and there is a development workflow that could make sense.

Particularly, I was considering how one could load https://github.com/addyosmani/traceur-todomvc without a build step when in development.

The basic idea would be to compile the ES6 with Traceur before execution. For an example of this see https://github.com/guybedford/es6.

Basically it would be added as a "translate" step in the loader:

  System.translate = function(source) {
    // copy code from https://github.com/guybedford/es6/blob/master/es6.js#L4
  }

The integration is actually quite simple as all the code is readily available. The question is whether we want to encourage this or not?

https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/es6-module-loader.js#L449

While this is the difference between an 800KB parser and a 100KB parser, since this module is being used to polyfill ES6 syntax, we need to unify the parser and not have two parsers being used.

Additionally, this module can be used to polyfill module loading of all other module formats, without having to download the parser anyway.

The only use case that would suffer from using Traceur is for users who want to use ES6 module syntax with ES5 code. But that is what AMD and CommonJS are for anyway.

So I think this change can align the module quite nicely around the full ES6 workflow,

When importing code like:

export default ...

...

...I would have expected that such an export would cause the exported object to be directly available on the corresponding import callback argument without needing to get to it with the "default" property...

If this is the correct behavior, Is the "default" property specced anywhere?

Thanks...

IE10 doesn't and apparently hasn't worked when trying to access the global/_global properties. defineProperty does not appear to be the problem for IE10 (and IE10 can use Object.defineProperty on normal objects unlike IE8 which can only use it on DOM objects), but rather these lines at the top of the Loader constructor:

Global.prototype = options.global || (isBrowser ? window : {});
this._builtins = new Global();

Adding alert(this._builtins) gives an error here.

When the this._builtins property is used later, there are therefore problems there as well when access is attempted:

Global = function () {}
Global.prototype = this._builtins;

this._global = new Global();

Adding alert(Global.prototype); or alert(this._global); after the above lines gives an error too.

IE10 appears not to allow access if the window is used as another object's prototype (I also got the same errors when I tried iterating over the window's properties to assign them to the prototype instead of using window directly).

At the moment, each custom loader is using its own registry, but is this a good idea? It remains to be seen how browsers implement loaders, but for the moment ISTM it would be better if they all used the same one.

There should be a simple example project where using modules should help the development. It should also have quite many comments from devs. :)

Having spent a while working on jspm, I think it might just be possible to append functionality to the System loader instead of having an entirely separate loader.

I'm thinking of putting together a library as a "System addon" for things like AMD support, CommonJS support, map config, etc, which can be selectively included in the loader as needed, enhancing functionality.

A full list of features would be:

• AMD, CommonJS, and Global Shim support
• map config support
• plugin support

Effectively this would be a very stripped down version of the jspm loader, but appending its functionality to the System loader in a backwards compatible way.

Thanks to @probins for the initial inspiration on this.

What do others think? Also any ideas for names? SystemJS is the best I've come up with... could do with some creative input!

I can probably get a prototype up within a week, working out interest and how it is presented is probably the hardest part.

Currently the only tests are from the jspm-loader running against this.

We need to bring in a full test coverage here, including examples such as:

// scripts/crypto/random.js
export default function() { ... }

// scripts/crypto/guid.js
import random from './random';
export default function() { ... }

// test.js
import guid from './scripts/crypto/guid';
console.log(guid())

// bar/test.js
import guid from '../scripts/crypto/guid';
console.log(guid())

This is a more sensible default, and seems likely for the spec.

The source file should include the current version number.

I have a project that consists from ~100 modules (files). It doesn't make sense to compile all those files in browser each time when I reload the app. There should be a terminal option to build a single ES6 file with import/export statements into corresponding ES5 file.

Hey there

I stumbled upon Guy's post on polymers mailing list.

https://groups.google.com/forum/#!topic/polymer-dev/B1PTiENeuT4

It dates back to august, are there any new findings or experiences that you guys did in the meantime?

I personally do think that Web Components + Modularization are key to proper encapsulation in the UI so this is a long-awaited feature.

Thank you!
Alessandro

As the loader uses xhr, scripts/modules can only be loaded from CORS-enabled servers. The example at http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples#dynamic_module_loading won't load because the server is not CORS-enabled. Any plans to change this?

Returning the full module object

I've managed to adapt the loader to use the new "link" hook and updated the other hooks as documented here - https://gist.github.com/wycats/51c96e3adcdb3a68cbc3.

I have also included Esprima's syntax parser to fully support "import", "module" and "export" statements in loaded modules. The great thing about the Esprima parser is that it is only 60KB making the full polyfill less than 70KB minified.

I can provide this as a pull request if you are interested?

https://github.com/guybedford/es6-loader

https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/es6-module-loader.js#L505

isUrl returns true for strings ending with '.js' so the second if statement is never true.

@guybedford for the README:

1. Mention if loading a JS file (or files) is done sync or async
2. Document the pre-configured loader, all attributes. For example, what you mean with System.baseURL. What does the System object contain? (btw, System is a bit generic, perhaps use SystemLoader would be better). Include comments/document what each of the Custom Loader attributes does (ie normalize).

Thanks :)

While tracking down issue #45, I discovered that traceur-test.html cause esprima to be transcoded by traceur.

After we xhr the content of es6-file.js we call
fulfill(xhr.responseText);
which is fetch callback
this.fetch(url, function(source) {
opt.address = url;
opt.type = 'module';
source = self.translate(source, opt);
self._linkExecute(name, source, opt, _callback, _errback);
}, _errback, opt);
so we enter _linkExecute with the transcoding of es6-file.js.

There we call loadEsprima. But the loader is now transcoding all inputs.

At the end of translate:
source = traceur.outputgeneration.ProjectWriter.write(res, opt);
if (isBrowser)
source += '\n//# sourceMappingURL=data:application/json;base64,' + btoa(opt.sourceMap) + '\n';

we call btoa() on the sourceMap. I added the input source to the sourcemap to get around issue #45, and this source causes a DOM exception
"'btoa' failed: The string to be encoded contains characters outside of the Latin1 range."

Probably something to do with utf16 silliness new recent JS.

Maybe btoa() is a problem, but I don't think you want to transcode esprima in this scenario anyway.

Ideally the code should be adapted to work as a NodeJS module equally.

Then the System loader could potentially also support fetch in Node, or alternatively one would construct a loader for NodeJS environments.

Would be nice if this was written in ES6 using Traceur.

Since it's a polyfill for an ES6 feature it kinda makes sense.

This isn't currently the case and should be resolved :)

We can probably add links to:

• Unminified build
• Minified build
• Dependencies

along with some estimated size information.

A browser compatibility list might also be useful.

At least to avoid the loader getting stuck in a loop perhaps.

Since we're eval'ing, this content doesnt get added a script to the devtools.

Let's use sourceURL to turn this into a psuedofile so it populates in the devtools

@guybedford has done some incredible work taking this project further and I think it would help accelerate both testing and general usage by improving both our docs and the current site. I think the recent Traceur changes are worth making a splash about.

This could be something that might be worth exploring in Q1, 2014. I also think it would be useful to define what the goals for ModuleLoader are for next year. E.g:

Do we see ourselves as:

• A reference implementation that provides a stable, supported version of the draft work Mozilla has done on the loader spec?
• A reliable loader that we encourage other tools to build on and developers to use in their production apps - e.g JSPM has done a fantastic job building on the project and I could see others similarly switching over to using us.

Other questions:

• Do we want to push JSPM further as a part of these efforts and do we see it being ready for use in building either demoware or production-level apps too?. I think everyone that's seen it agrees its an amazing sister project, but don't feel its had (yet) the kind of uptake it could. What can we do to change that?

It would be good to have a single location to track areas of the specification still subject to change, and pointing to the relevant discussion.

To start -

• Bundling: The extra metadata property in the resolve function is currently aiming to allow metadata relating to the multiple IDs defined by a module bundle. This is still being worked out. Awaiting a link to the discussion emails.
• Fetch: The fetch function is given a different specification between the prototype (Loader.prototype.fetch) and loader instance (options.fetch). This seems to be a spec issue.
• System loader resolution: It is still unclear how exactly the js extension is handled. For example, it is unknown whether file.coffee.js should normalize to file.coffee or not.

The fetch function is given a different specification between the prototype (Loader.prototype.fetch) and loader instance (options.fetch).

As instance functions are provided on the instance object as in the @wycats essay (System.normalize, System.fetch etc), there seems to be a conflict between these.

We should address this.

The full update to the latest specification has just been merged into master. After further testing this can become the 0.4.0 release.

This entirely implements the specification algorithms to the letter now, with all exceptions fully documented.

Feedback and testing welcome. Suggestions on making the readme clearer also very welcome.

The top section of the source file should include the date of the currently implemented specification draft. When es6 is ready, it will mention the final specification details.

I think that we should consider tagging a new release before more work is done on the roadmap. This will at least give developers a semi-stable point they can try out while development is on-going in master.

Variables defined in the ES6 parser function will be leaked into the eval scope. The eval statement needs to be properly wrapped before execution to ensure only wanted variables leak through.

As the ticket says.

Hi,

Exciting to see this project!

I just installed through npm and got an error...Should esprima not be listed as a dependency in package.json?

Thanks...

Based on this post: http://esdiscuss.org/topic/modules-vs-scripts#content-2

Is there any interest in supporting some form of this? I might be interested in working on it if it's something desired.

It is still unclear how exactly the js extension is handled. Unlike RequireJS, the .js extension does not imply a URL and still gets normalized. The question then is whether file.coffee.js should normalize back to file.coffee or not. Awaiting further spec discussion.

It is including the //# sourceURL comment, but source maps are necessary to maintain the syntax with the original source. Should be straightforward with the data-uri approach.

The source file should the strict keyword for JS.