Module naming and declarations
Anne van Kesteren
annevk at annevk.nl
Tue May 7 13:33:36 PDT 2013
On Tue, May 7, 2013 at 1:22 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Tue, May 7, 2013 at 4:01 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> How is that not treating it as a URL with a dose of magic by default?
>> E.g. import "http://code.jquery.com/jquery-1.9.1.min" will work given
>> the way things are defined now. Similarly if I put jquery in root
>> import "/jquery-1.9.1.min" will always work, regardless of location.
>> This might not be how things are intended to be used, but I'd expect
>> to see this kind of usage.
> Using an absolute URL (as in your first example) opts out of any
> processing. Otherwise it wouldn't work, of course -- adding the
> baseURL would break that URL.
"Adding"? What's the actual processing model for the default loader
here? I thought it was:
1. Append ".js" to module name.
2. Use the URL parser to parse module name relative to base URL.
3. Fetch result of that operation.
> In the second case, what is the complain? That's a reasonable module name.
If that's reasonable you might as well not add ".js" by default and
require that to be specified if people want that. (Tying file
extensions to content is dubious in a web context in general.)
> The whole point of my original email to Andreas is that this doesn't
> work. These names are *not* intended to specify where to find the
> resource. They *are* intended to be names that different modules can
> coordinate with. Should backbone put `import "/js/jquery.js"` in
> their source file?
If backbone has its own loader and everything it doesn't really matter
what the default semantics are.
More information about the es-discuss