Module naming and declarations

Andreas Rossberg rossberg at
Thu May 2 07:47:06 PDT 2013

On 1 May 2013 00:01, David Herman <dherman at> wrote:
> On Apr 29, 2013, at 6:34 AM, Andreas Rossberg <rossberg at> wrote:
>> are generally assuming the use of some package manager. This
>> is a fairly significant assumption, that I wished I had heard being
>> made explicit in any of the previous discussions. AFAICT, it is key,
>> and without it, your proposal cannot fly. Not in a world with tens of
>> thousands of module releases, anyway.
> Not only is this wrong -- it'll be just fine to use ES6 without package managers -- but your proposal does not make any material difference in the relative dependence on package managers.

I don't see how logical names can possibly make sense without at least
a rudimentary manager that maps them. Otherwise they are just physical

My point on the topic of external naming is that the language (1)
should not prescribe any specific naming scheme; (2) should not
willfully violate URI semantics; (3) should properly separate it from
internal naming.

Package managers are great, and I agree that they will (and should)
become part of the eco system. But leave design decisions to them, and
don't limit their options a priori. I'm not sure why we even disagree
on that.

>> More specifically, everything should still play nice with standard web
>> mechanisms. For me, the web platform implies that I should be able to
>> address modules as remote resources (it's a choice _not_ to use that
>> mechanism). That requires that the system allows proper URLs as module
>> identifiers.
> Fully agreed, and if it wasn't clear, the current system does completely support this. You can use a URL as a module name. In the default browser loader, you can choose to import a module from an explicit URL:
>     import { $ } from "";
> and it will use that URL both as the logical name and as the place to go and fetch the bits.

OK, great! Can I also use such URLs for module definitions then?

> If you don't use an absolute URL, it treats it as a path, which defaults to loading as a source file from a relative URL derived from the module name.

And here we get to the core of the problem. Namely, how do you
interpret relative and absolute here? URLs have a very clear
semantics: everything that isn't absolute is relative _to the
referrer_. So far, everything I have seen in any of the recent module
specs or presentations is a blunt violation of these semantics.

In particular, as I mentioned before, you _cannot_ make "a" mean
something different than "./a" without violating URLs [1,2]. Yet that
is not only what you envision, it is what you de facto _prescribe_
with your proposal. I think that's simply a total no-go.


>> That does not mean that logical names have to become unreadable or
>> awful to type. Just that they are slightly more explicit. A schema
>> prefix -- say, jsp: for a random strawman -- is good enough and should
>> not offend anybody in terms of verbosity. (If it did, then I'd have
>> little hope for the evolution of the web platform. :) )
> First, let's be clear: this is literally an argument over the surface syntax of public module names, nothing more. You're arguing for the universal  addition of a few characters of boilerplate to all registered module names. That's just bad ergonomics for no gain. Not only that, it hurts interoperability with existing JavaScript module systems.

I don't see how it hurts interop. It just means that you have to find
a convenient _and_ proper way to embed a logical name space into URLs.
I proposed using a schema, but anything that is compatible with URL
semantics is OK. Just taking AMD-style strings verbatim is not.

It is not something which you can justify with AMD/Node precedence
either, since AFAICT these systems do not have the notational
overloading between logical paths and URLs that you propose.

> There's a reason why the existing systems favor lightweight name systems. They're nicely designed to make the common case syntactically lighter-weight. And they absolutely can co-exist with naming modules directly with URL's.

Sure they can coexist. But please not by bastardizing URL semantics.


More information about the es-discuss mailing list