Module naming and declarations

Jason Orendorff jason.orendorff at
Tue Apr 30 10:11:26 PDT 2013

On Mon, Apr 29, 2013 at 4:50 PM, Brian Di Palma <offler at> wrote:
> I was wondering how versioning was expected to work in this module system.
> [...]
> 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.

The simplest thing would be to make a jquery module in your component:

    module "megabank/metals/jquery" {
        import $ from "jquery-1.9";
        export $;

    // other modules under megabank/metals/ would write:
    import $ from "./jquery";

That's the way that's built in the system, and that's what I would probably do.

Loaders are customizable, so one alternative is to add versioning to
the system loader:

> With nested modules maybe you could bundle them like so
> module Metals {
>     module jquery {
>       //jquery 1.9.
>     }
> }

Do you imagine the whole Metals module being in a single file,
including jquery? Or would lexical modules be "open", like C++
namespaces and Ruby classes? Or would they be put together some other

Having to paste jquery code into your project seems unfortunate. You'd
rather use the files unchanged, right? Also, if jquery imports
something, and the name happens to collide with something you've
declared in Metals, wouldn't jquery break?  (Well, OK, the real jQuery
doesn't import anything and is extremely careful about which global
names it uses. But one goal of a module system is not to have to be
quite so paranoid.)

Closing thought: All use cases are welcome! That said, using multiple
versions of a library in a project is icky enough that an occasional
project-wide search-and-replace at the margin isn't much worse.


More information about the es-discuss mailing list