Module naming and declarations

Jason Orendorff jason.orendorff at gmail.com
Fri May 10 12:29:10 PDT 2013


On Thu, May 9, 2013 at 4:42 AM, Sebastian Markbåge <sebastian at calyptus.eu>wrote:

> My biggest concern is that people will assume a certain structure of the
> module path. Then they will assume that relative paths and logical names
> can be used interchangeably.
>
> E.g. if I'm inside of package "a/b.js" I can access a top level package
> using either "../backbone.js" or "backbone". I may even use both patterns
> in the same package.
>

You could import "../backbone", a relative module name (note that it's not
a relative URL; the proposed default loader never treats module names as
relative URLs). It's just extra typing, though—the normalize hook will
convert that to "backbone" right at the beginning of the import process,
and from then on the two styles really are exactly identical. I don't think
it could cause any portability problems.

Most of the time it'll work because that file structure is common enough.
> That will eventually force everyone to use this file structure if they want
> to reuse modules that mix these patterns.
>

I don't think this could possibly happen under the proposal, because
relative module names aren't URLs.

The pipeline is
    normalize -> resolve -> fetch -> translate -> link
and relative module names are processed at the first step, normalize. This
is before the resolve step, which figures out the URL.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130510/5f0e8308/attachment.html>


More information about the es-discuss mailing list