Module naming and declarations
jason.orendorff at gmail.com
Mon May 6 16:43:43 PDT 2013
On Fri, May 3, 2013 at 9:22 PM, Kevin Smith <zenparsing at gmail.com> wrote:
>> Do we? It seems to me that "filenames as import-specifiers" is a
>> design option that has been available to, and rejected by, all of the
>> JS module systems and all recent programming languages, except PHP.*
>> And the reason seems obvious enough: hard-coding a library's location
>> into every import site is bad.
> First, I assume that you're just referring to inter-package dependencies.
> Relative paths are fine for a library's internal modules.
Well, yes and no. Relative paths are fine for development; Sam and
Andreas have been discussing (in this thread) what happens when you go
to production and you want to put all that in one file. It seems
better not to be embedding URLs in code, even relative ones, just
because it makes concatenation more complex. I don't think we want it
to be considered normal for your production code to *look* like it has
a bunch of relative URLs in it, when in fact the loader is rewriting
or ignoring them all. Too misleading. (An ahead-of-time-compiled
system like Dart might not care about this; for the Web I think we
Earlier I think you suggested making everything to do with
inter-package dependencies out of scope for ES6. That doesn't make
sense to me. Code using a package manager should be able to use import
syntax to get packages. So package managers will need to slot into the
system we're designing.
I want it to be easy to start out hacking on a web page with
import "jquery" as $, "underscore" as _;
and add a package manager next week. Adding a package manager
shouldn't be required, but it shouldn't be disruptive either if you've
done the usual stuff. In particular the default should be that if I
write a package that uses underscore, you should be able to import my
package without switching to the package manager I use—and ideally
without using a package manager at all.
> Second, I'm well aware of the issues you point out with using URLs or file
> paths for inter-package dependencies. I think URLs *can* perhaps do some
> interesting things for us here which we haven't seen yet, but I'm not
> arguing against using a flat namespace.
I would like to hear more about that when you're ready -- I think the
default relative-ness of URLs makes them unsuitable when what you want
is a flat namespace.
> But (and this is the key) such a flat namespace must be layered on top of
> URLs. It cannot *overload* URLs as the current design attempts to do. Why
> not? Because such an overloaded semantics would conflict with the
> resolution semantics as defined by the platform in HTML, CSS, etc. Truth,
> beauty conceptual integrity, and all that good stuff. : )
I can totally understand not wanting module names to be ambiguous with
URLs or look like relative URLs but behave totally differently. As
Dave said, that's a surface syntax issue (which is not to say it's not
But I still don't see why we should layer something on top of URLs
when we already know users strongly prefer that it *not* be coupled to
More information about the es-discuss