TypeScript 2.0, tsc issue when having @types in symlinked node_modules

[TautvydasDerzinskas]

Long story short, our build process before firing "npm start" command creates symlink to node_modules folder in the root folder of the project taking it from some other place.

Our npm start command setup in package.json:

  "scripts": {
    "prestart": "npm install",
    "start": "tsc @App/Other/Gulp/preCompile.txt && gulp build",
...
  }

So it does run npm install, but because we symlinked the node_modules and npm detects all packages installed, it jumps into "tsc @App/Other/Gulp/preCompile.txt" but this fails, because compiler tries accessing files both from symlink local folder "node_modules" and original "node_modules", exact lines from log:

> tsc @App/Other/Gulp/preCompile.txt && gulp build
../../../../../../Resources/Development/node_modules/@types/angular/index.d.ts(17,21): error TS2300: Duplicate identifier 'angular'.
../../../../../../Resources/Development/node_modules/@types/angular/index.d.ts(18,21): error TS2300: Duplicate identifier 'ng'.
node_modules/@types/angular/index.d.ts(17,21): error TS2300: Duplicate identifier 'angular'.
node_modules/@types/angular/index.d.ts(18,21): error TS2300: Duplicate identifier 'ng'.

I have tried setting typeroots in tsconfig.json to "node_modules/@types" which is default value, but it did not help. Seems like it could be typescript 2.0 bug, as the original path is relative to the project root...

[leonyu]

Is there currently a workaround? Having this issue with our production setup.

[nibblebot]

@SlimDogs I was able to fix this for my symlinked setup with typeRoots: [] which removes the default one entirely.

[jasonswearingen]

@nibblebot can you please provide more details? I would love to get this working for my project too.

For example, did you add typeRoots:[] to the consuming project, or to the library that was being symlinked?

thanks much!

[jasonswearingen]

@nibblebot thank you for that hint.

I was able to add

"types": ["node", "mocha"],
    "typeRoots": []

to all of my projects (the library and it's consumers) and that fixed all the errors. now I "only" get the following warning when compiling the consumer:

message TS4090: Conflicting definitions for 'node' found at 'C:/repos/stage4/slib/node_modules/@types/node/index.d.ts' and 'C:/repos/stage4/xlib/node_modules/@types/node/index.d.ts'. Consider installing a specific version of this library to resolve the conflict.

but everything now compiles and I can do hot development in the library without having to npm publish round-trip.

However, if I npm link the consumer and consume that in a 3rd project, it falls apart, as it looks like the tsc compiler gets confused from the nested-ness (in my case, it thinks both the first and second projects declare bluebird but it's actually only in the first)

[MortenHoustonLudvigsen]

I have experienced this as well.

The reason, as far as I can tell, is that, when a package is linked npm does not flatten the packages used by that package. This means that if you reference f.eks. package @types/node in a package and in a used package, that is linked, @types/node will be in the node_modules folder twice.

For some reason the TypeScript compiler "sees" both copies of @types/node, and because @types/node contains global definitions conflicts occur.

Because of this issue we have moved away from using links in development. We now have a watched build task, that installs local packages whenever there are file changes in the local packages.