Module naming and declarations

Kevin Smith zenparsing at
Mon May 6 20:02:39 PDT 2013

> 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.

That's when you want to bundle sub-modules together into a single module.
 That's one reason why we need lexical modules - so that we can bundle up a
library's internal modules without dumping a bunch of useless entries into
the "global" module table.

Really, we need lexical modules.

> 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 suppose that's a reasonable position to take.  I could argue that a
module loader API provides enough of a slot.  I mean, you should be able to
implement a custom "package:" scheme in just one line:

    System.resolve = url => /^package:/.test(url) ? `${ this.baseURL
}/packages/${ url.replace(/^package:/, "") }.js` : url;

    <script async>
    import $ from "package:jquery";

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.

Sure - but that's tricky, opinionated business in general and it deserves
an entire debate of it's own.  Regardless, we shouldn't even be having that
debate until we have a solid module system in place.  Again, inter-package
dependency resolution should be layered on top of the core module system.
 In the current design, it is conflated.

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
> important).

I don't think so.  I think the current design is entirely wrapped up in
modeling modules as "logical" names in some flat namespace.  It is central
to the design rather than layered on top, as it should be.

> 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
> locations.

A custom scheme would layer on top of URIs just fine and would only take a
handful of lines of code to implement:

    import $ from "package:jquery";

Are you opposed to such URIs?

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list