This project is read-only.

How do you put multiple external modules into the same namespace?

Topics: General
Oct 14, 2012 at 3:03 PM
Edited Oct 14, 2012 at 3:10 PM

Say I want to have one class per .ts file. I have two .ts files, that look like so:

    export module MyClasses { export class A {} }


    export module MyClasses { export class B {} }

I can't do this:

    import MyClasses = module('A');
    import MyClasses = module('B');

How do I define classes in separate files and put them into the same "namespace"? Furthermore, we end up having to do something like:


instead of


What's the point of this additional level of hierarchy? So that you can have more than one exported module in a module file? The best solution I've figure out so far is to remove "export module" (since "export class" seems to be sufficient when compiling AMD), which moves the class up one hierarchical level. Then:

    import AModule = module('A');
    module MyClasses{ var A = AModule.A; }
    import BModule = module('B');
    module MyClasses { var B = BModule.B; }

Though it works perfectly, it's not exactly succinct. Is there not a better way to do this? Honestly, I'd rather have something like:

    import "A";

that imports all the top level exports (modules, classes, etc) into the current scope.

Oct 14, 2012 at 3:18 PM

For multiple files as one module see this post: (although not a great solution).

For the extra level of indirection, try skipping the module altogether.  In your module file use:

export class MyClass {

Then in the consuming code use:

import mymodule = module("myclass");
var x = new mymodule.MyClass();

I would say that the module keyword is now a bit misleading.  If a module is always a file, then this is fine - but then I don't understand what we gain by having "export module" for external modules.

Oct 14, 2012 at 4:20 PM

If all you want the import for is compile-time checking, and your code will eventually be compiled into a single .js file, you can just use a <reference> instead of an import.


module MyClasses {
    export class A {
        constructor(public a: string) {}



module MyClasses {
    export class B {
        constructor(public b: string) {}


/// <reference path="a.ts" />
/// <reference path="b.ts" />
var a = new MyClasses.A("foo");
var b = new MyClasses.B("bar");
console.log(a.a + b.b);


tsc --out app.js app.ts a.ts b.ts

Oct 25, 2012 at 7:16 AM
Edited Oct 25, 2012 at 2:23 PM


The big 'IF' implied by your solution is "if ... your code will eventually be compiled into a single .js file ...".  

Now for my NodeJs development I use VS 2012 with the Web Essentials extension (which is great by the way) and on save, it compiles your TS file it into a corresponding .js file.  So that eliminates the assumption of your solution.

Also, we are undertaking a large NodeJS project and what is a common pattern in our 'modular' system is to extend/configure these 'namespaces' based on a target platform/audience by including various TS files in various combinations.

In other words, say we had a 'Models' namespace we may have a core set of entities in that Models, say 'Entity' and 'NamedEntity'.  Now in plain JS we can extend that Models namespace by simply assigning another model to 'Models', say 'Person'.  This means 'Models' now contains all our models, 'Entity', 'NamedEntity' and 'Person'.  Having all our models in a common 'namespace' means I can write libraries (such as an ORM) that can provide common behaviour to all models collectively.

If someone can show me how to achieve this (in NodeJs specifically) and still have the benefits of TypeScripts intellisense I'll be a happy camper!

I see being able to extend a 'namespace' in NodeJS by importing multiple modules into a single 'namespace' as a important, if not critical, mechainsm missing from TypeScript.  This mechanism is as a common mechanism for extending base libraries in NodeJs and in the browser.