Module naming and declarations

Brian Di Palma offler at
Mon Apr 29 14:50:02 PDT 2013

I was wondering how versioning was expected to work in this module system.

Let's take the example of a large institution with many separate
development groups.
These groups do not collaborate and do wish to depend on each other.
They all produce components that are to be integrated into a large
single page application.

Group 1, let's call them "FX" create a component that uses JQuery v1.8.
Group 2, "Metals" create a component that uses JQuery 1.9.
Group 3, "Equities" create one that uses JQuery 2.0.

Now in each teams code base JQuery is imported like so:

import $ from "jquery";

That's great as long as they are developing separately from each other.
What I'm wondering is how their components are meant to be integrated
into a single app.

With nested modules maybe you could bundle them like so

module Metals {
    module jquery {
      //jquery 1.9.

module FX {
    module jquery {
      //jquery 1.8.

module Equities {
     module jquery {
       //jquery 2.0.

Everyone has their own jquery local reference and everything is OK.

Without nested modules though how should this work?
The first jquery module grabs that identifier and the rest end up
throwing an error from what I can tell.

I suppose the bundler tool is meant to be clever enough to rewrite all the
module identifier when creating the single page app deployment artifact?

So we end up with

module "jquery:1.8.0" {}

module "jquery:1.9.0" {}

module "jquery:2.0.0" {}

This also means that all the code from each team needs to be rewritten
by the bundling tool to

import $ from "jquery:1.8.0"

The other possibility of having each import have a hard coded version
in it is frankly a non-flier.
What I mean is having each import statement in the form
"identifier:version" as convention.
That might work if you have a few packages that you are working with
but if you are writing class
based code were every class is a module and you have hundreds of
classes you are going to have
some really ugly issues with doing a global search and replace of
versions to newer version as you
might end upgrading some classes/modules that you never meant to.


import MyLittleFxTicket from "class:1.0.0";
import MyUtility from "otherclass:1.0.0";

You may want to update all uses of the classes in the package that
contains "class" as one of it's classes
but _not_ "otherclass". So hard coding versions into the identifiers
is just a no go.

Has any thought been put into this version issue? Large companies
would be likely to find this a pain point.

Also what is the actual issue with reverse domain names as a form of
identifier, it seems a perfectly
acceptable one. Some comments were made about how Java uses it and
it's not acceptable/good enough
but there was no evidence provided to back that claim up. Personally
I've never had issues with it.

For organizations it's excellent

com.megabank.metals / com.megabank.fx

is a clean, simple way to avoid clashes. What's wrong with

import $ from "org.jquery";



On Mon, Apr 29, 2013 at 5:09 PM, Sam Tobin-Hochstadt <samth at> wrote:
> [Responding to these two emails together]
> On Mon, Apr 29, 2013 at 6:40 AM, Kevin Smith <zenparsing at> wrote:
>>> The URLs you're proposing here just *are* logical names, and they
>>> aren't in most cases being dereferenced to produce resources, which is
>>> the core point of URLs on the web. They're just inconvenient logical
>>> names.
>> No.  In my hypothetical scenario they are simply URLs which when
>> dereferenced produce the required source code.  They are "canonical", in a
>> sense, and can be remapped to other URLs, but they are URLs, nonetheless.
> To make this concrete, what you suggest is that any code that depends
> on jQuery will need to write:
>     import $ from "";
> Because that's the canonical URL for the current version of jQuery.
> Then, anyone who wants a version of jQuery that is not that version
> will have to set up a URL rewriting scheme, probably as part of a
> loader. Of course, absolutely everyone will want to use a different
> version of the code than this; it's not even minified, let alone
> served on a CDN, or over HTTPS, or on a local site, or any of the
> other concerns people will have in production.  Even worse, this bakes
> in a particular version.  If I want to upgrade to 1.9.2 when it comes
> out, what do I do?
> Further, you can't load a module that defines jQuery with a script tag
> -- how would that define the same module that the URL above specifies?
>> You have not demonstrated that a URL-based semantics would not work.  Only
>> that "Sam doesn't like it".
> I've spent a lot of time in the discussion spelling out precisely the
> technical problems with the URL-only approach.  I assume you can tell
> the difference between that and "Sam doesn't like it".
>> But I thought that was one of the original
>> design goals of the module loaders API:  to allow users to apply whatever
>> arbitrary URL resolution semantics they like.
> It is a goal of the module loaders API to allow users to configure,
> restrict, redirect, etc the URL retrieval behavior.  This is important
> for caching, bulk loading, security restrictions, etc.  It is _not_ a
> goal to force every user to use the module loaders API just to host
> some libraries locally.
> On Mon, Apr 29, 2013 at 6:44 AM, Kevin Smith <zenparsing at> wrote:
>> I understand this design now.
> This does not appear to be the case.
>> At scale, it depends upon an implicit,
>> centralized naming authority to manage naming conflicts.  The namespacing
>> scheme of this authority will necessarily be flat because it will be seeded
>> with names like "jquery" and "ember".
> This is false. We do not assume any naming authority, and have never
> said that we did. Similarly, neither the AMD module namespace nor the
> JS global object have a "naming authority" to manage conflicts.
> How did you get the impression that this was required?
> In another domain, there's no "global authority" to manage the file
> system on, say, linux systems, although there are multiple package
> managers.
> I assume that package managers for the browser will appear; in fact,
> some already exist. That doesn't mean there will be a central
> authority.
>> Who's authority will this be?  Google's?  Mozilla's?  Apple's?  Twitter's?
>> Node's?  Who will be responsible for maintaining it?  What will the
>> conflict-resolution strategy be?  Will names be immortal?  Will there be any
>> standard conventions?  Will it support versioning?
> Again, no one will be required to use any package manager.  Google
> *already* ships a tool that manages a namespace (the Closure
> compiler), but no one has to use it to use the global object.
>> All of these questions will be left unspecified (because ES6 will surely not
>> specify them), and as with all unspecified needs, a path-dependent and quite
>> possibly sub-optimal solution will emerge.  Javascript, to some degree, will
>> be bound to this autonomous naming authority, like it or not.
> If JS develops package systems, then I'm assuming that they'll
> competitive, and that people will work hard to develop good ones.
> Certainly systems like NPM are excellent, and we should not assume
> that the JS community will do worse on the web.  But JS will not be
> bound by it.
>> I think some accounting would be helpful here.
>> As far as I can tell, the proposed resolution semantics would take about 10
>> lines of code to write using a module loader API.  Let's be generous and say
>> that it really comes out to 20 lines.
> What "resolution" semantics are you talking about? I can't think of
> anything in the semantics that answers to this description.
>> - We are drawn inescapably toward an unspecified central naming authority
>> whose policies we cannot foresee or control.
> An actual argument for this, rather than repeated assertion, would be useful.
>> - We break a central tenet of the web (1):  that external resources are
>> represented by URLs.
>> - We break a central tenet of the web (2):  that naming authority is
>> decentralized using DNS.
> This is no more true of the module system than that the HTML `id`
> attribute violates this principle.
>> On the bright side, we have an excellent design that we can return to:  Sam
>> and Dave's pre-November lexical modules.
> As I explained in some detail in my response to Andreas, this design
> has a significant flaw, which we fixed, leading to the current design.
> Sam
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list