Understanding the 'normalize' Loader hook

John Barton johnjbarton at google.com
Tue Aug 12 15:00:05 PDT 2014

On Tue, Aug 12, 2014 at 2:45 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 12 Aug 2014, John Barton wrote:
> >
> > See the implemention in es6-module-loader:
> >
> https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/system.js#L117
> Ah, fascinating. So basically:
>  - "normalize" does relative URL logic based on the current base URL and
>    the referrer (i.e. the URL of the script doing the importing).

I would expect that normalized names to be platform independent.

>  - "locate" resolves that URL and adds ".js"

This step is platform dependent, it produces an address from a name.

> (only if the last segment
>    is part of the "path" part of the URL and doesn't contain a "."?).

No such restriction is applied in our code.

> Is that more or less right? (There's also the loader.paths stuff. Why is
> that in "locate" rather than "normalize"?)

Because the paths processing can produce arbitrary addresses (to cache,
CDN, I guess)

> (BTW, I noticed that both in that code above and in the spec, "referrer"
> is consistently misspelt as "referer", the HTTP way.)

I've already reported this bug.

> I'm exploring some ways that the module system could be extended on the
> Web platform.

 You might look at Guy Bedford's experiment on loader plugins
 that follow the path laid down by Jame Burke in requirejs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140812/c2aff925/attachment.html>

More information about the es-discuss mailing list