Module naming and declarations

Sam Tobin-Hochstadt samth at
Wed May 8 11:14:06 PDT 2013

On Wed, May 8, 2013 at 2:08 PM, Domenic Denicola
<domenic at> wrote:
> From: samth0 at [samth0 at] on behalf of Sam Tobin-Hochstadt [samth at]
>> How is this in disagreement with what Jason said?  His point is that if you're in the module "a/b/c", "./controllers" refers to "a/b/controllers", and "backbone" refers to "backbone".
> Ah, I see, there are two levels of translation! First from "non-canonical module IDs" to "canonical module IDs", which in this case means from `"./controllers"` to `"a/b/controllers"`, and then another from "canonical module IDs" to URLs. It's confusing since there are two concepts of "base" in play: the current module's "canonical module ID" is used as a "base" when resolving "non-canonical module IDs", and the base URL is used when resolving "canonical module IDs" to URLs.

I would say "module name" and "relative module name" for the two terms
you're looking for here.

> But, even then, that seems at least somewhat at odds with what Jason said. He implied that `"backbone"` would resolve to the backbone package, and not to the URL `""`. In particular, he contrasted "some other package" (Backbone) with "a module in the same package/project," which to me would be modules under `""`. I look forward to finding out which part I misunderstood :).

I think what Jason meant by "a module in the same package/project" was
just that it's something that you expect to be a part of your package,
and thus would refer to with a relative name.  It's important to use
relative names for that so that your code can be dropped in anywhere
and have the module references continue to work.

In contrast, usually you want to be using that global version of
"backbone", not something specific to your library.  Of course, you
can bundle backbone, and refer to it with "./backbone" if that's what
you want, but that's probably a less-common case.


More information about the es-discuss mailing list