Typing for nested modules doesn't seem to work

[zpdDG4gta8XKpMCd]

So basically it looks like typings for npm modules only work for immediate modules. A typing that depends on a nested typing cannot export nested types.

I created a repository that illustrates the problem: https://github.com/aleksey-bykov/nested-typings-problem

If you would first build the inner module by running:
https://github.com/aleksey-bykov/nested-typings-problem/blob/master/node_modules/b/i-will-build.bat

And then try build the outer module by running:
https://github.com/aleksey-bykov/nested-typings-problem/blob/master/i-wont-build.bat

You will get:

index.ts(2,12): error TS4023: Exported variable 'program' has or is using name 'ts.Program' from external module "node_modules/b/node_modules/typescript/lib/typescript" but cannot be named.

What am I doing wrong? How is this supposed to work?

[mhegazy]

there are two issues here. first the error. The error means that the declaration emitter is trying to write a type annotation in the generated .d.ts and could not come up with a valid name. This happens either because the name is not accessible in the current scope, or that it is shadows by another declaration with the same name.

In this case it was the first, in export var program= b.compile([], {});. the compiler will not add an import statement that was not there, instead it will ask you to either make sure the type is imported, or give it an explicit type annotation.

So to fix the issue, either type it export var program: SomeType = .. or import the type it needs as import {Program} from "typescript";

Now, this will take care of your error, but soon you will run into another issue, I have noticed that you have two copies of typescript in two different levels of node_modules. this means that the module will be loaded twice, once from each module, and then you will be doing structural type comparisons between the two copies; this wastes a lot of compile time, but that is not the issue here. The main problem is constructs that compare nominally (i.e. enums and classes/interfaces with private or protected members), these comparisons would fail. this is issue: #4800.

The work around is to use npm --dedupe or use npm 3 + which will flatten modules by default. the other solution we need to do on our end is to allow enums to structurally compare see #1748

hope that helps.

[zpdDG4gta8XKpMCd]

that did help, thank you