Modules, Concatenation, and Better Solutions

Luke Hoban lukeh at microsoft.com
Wed Oct 17 18:16:21 PDT 2012


From: Patrick Mueller
> On Wed, Oct 17, 2012 at 5:04 PM, Russell Leggett <russell.leggett at gmail.com> wrote:
>>     module "a.js" {
>>        import b from "b.js";
>>        console.log("a");
>>        export let a = "a";
>>    }
>>    module "b.js" {
>>        console.log("b");
>>        export let b = "b";
>>    }
    
>>    //main.js
>>    import a from "a.js";
>>    console.log("main");
    
>> The idea here, is to allow a new bit of syntax where the module identifier is a string literal. If that is the case, it assumes the module is loaded in place of a file, where the url for the file is the value of the string literal. Just to be clear, though, it doesn't actually execute the module at all - it just caches it in the loader.

> Ya, I kinda like that.  Basically let's me mark an "internal" module as an "external one" - I even get to assign a "file name", which maybe a debugger can make sense of.  Win!


Of note, TypeScript currently uses a similar syntax to solve a variant of this problem.  To describe the surface area of an API like the core node.js modules, we wanted a way for a single file to describe all of the modules that are made available within a bare node.js installation.  This includes the ability to declare:

declare module "http" {
  export function get(options, callback);
  //...
}

Indicating that a module named "http" exists and has the listed members.  TypeScript does not yet support a syntax for actually implementing a module using this form, but Russell's syntax is almost exactly what would make sense as a logical extension of the declaration syntax. 

The key difference between internal module definitions and Russell's inline external module definition syntax is that the later creates no lexical binding at the site of its declaration, and just puts an entry in the loader table.  This feels to me like a clean way to support the concatenation scenarios discussed in this thread, while still supporting the IIFE module patterns that motivate internal modules.

Luke



More information about the es-discuss mailing list