TypeScript: Using "import" makes my namespace/module unavailable in other classes.

I have 2 TypeScript modules like below. In the second module when I import a module, the classes, modules in the same namespace won’t be accessible ( seems they don’t exist ).

MyName.Modules.ts:

module MyName.Modules{
    export class Class1 {
        Name:string;
    }
}

MyName.Modules.Extras.ts:

/// <reference path="MyName.Modules.ts"/>
/// <reference path="nunjucks.d.ts"/>

/* if I comment this line of code MyName.Modules.Class1 is available
and if I won't do it TypeScript compiler can't find it.
*/
import * as nunjucks from "nunjucks";

module MyName.Modules.Extas{
    export class Class2 extends MyName.Modules.Class1 {
        public DoNothing():void{

        }
    }
}

P.S: nunjucks.d.ts is just an example, It doesn’t matter what you import …

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 16 (9 by maintainers)

Most upvoted comments

This needs to be re-designed. If later on an import is required into a file that originally had no imports, that would create a ripple effect throughout the entire code base.

MoonStorm on Jun 2, 2016

FAQ entry: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-did-adding-an-import-or-export-modifier-break-my-program

mhegazy on Apr 12, 2016

Thought I’d chime in here, because it was just last week that I was complaining about this.

It is super unintuitive to go from using namespaces to using file modules. There’s something inherently jarring about having individual files “knowing” about other individual files, physically (without additional work). I think the disappointment as far as being a TypeScript consumer goes is that there wasn’t some whizbang magic solution that preserved the behavior of namespaces in TS files and completely hid the notion that one potential implementation of a namespaced system is by using window level globals.

From my POV, TS should be smart enough to allow the conveniences of namespace syntax while still, behind the scenes, following modern module loading patterns. The fact that it doesn’t makes me think that there should be big red tape everywhere we mention using namespaces saying “Absolutely do not do this, you will regret it in 1-12 months”.

brphelps on Nov 23, 2016

Thanks for that @aluanhaddad . The situation is much more clear now.

So what’s the solution then? Keep everything in one TS file? Have one module per TS file? No thank you. It seems that the only common sense proposition for medium to large scale projects would be to code in a module-less manner and mash everything up at build time, however in this case the entire module support in Typescript can be thrown out the window. What is the general consensus on the matter?

MoonStorm on Jun 2, 2016