Module naming and declarations

David Herman dherman at
Mon May 13 17:37:11 PDT 2013

On May 10, 2013, at 7:18 AM, Andreas Rossberg <rossberg at> wrote:

> Can you explain how one form of module declaration is easier to "move
> around"? In a single script there surely is no difference.

Clients of a module can write:

    import { f } from "foo";

and regardless of how the module "foo" is shipped -- in a separate file or with an explicit module declaration in a bundled file -- the client code is unperturbed. This means that a single package can easily be deployed with any number of files without affecting client code.

> OK, perhaps I am under wrong assumptions about the semantics of
> ondemand. I assumed that when you first import a module that has been
> registered via ondemand, the respective script will be executed,
> recursively, and then linking of the outer script continues, taking
> the updated loader environment into account.

OK, this is a big difference between your imagined system and the current one. The current system does not execute modules until dependencies have been fetched and linked -- I explained this in the March meeting. (The .ondemand method is sort of a distraction; it's nothing more than an API convenience layered upon the underlying resolution hook.) This means that cyclic dependencies work, and dependencies are resolved statically across multiple files, causing a full static dependency graph to be concurrently fetched.

What you describe has a sharp distinction between packages and modules, where packages cannot have cyclic dependencies, must be dynamically loaded and registered, and are composed only of lexically scoped modules. What this seems to mean is, to implement a package (such as a library, application, or component of an application), you have to choose from one of three options:

- implement the package in one big file.
- implement the package in multiple files via some extension to ECMAScript (e.g., include) that requires a tool to assemble it back together in a single file with only lexical modules.
- split the package into smaller packages, each comprising only one or at least very few modules, forgo any cyclic dependencies, and effectively get little to no benefit from lexical modules.

Please do tell me if I'm missing something, because all of the above scenarios seem obviously impractical. In particular, it's a necessity that the system should work well out of the box, with no additional tools. Obviously large and sophisticated applications will be willing to buy into additional infrastructure, but you should certainly be able to put a package's modules in separate files without build tools.


More information about the es-discuss mailing list