Typescript: Typescript@next and npm linked node_modules

[cortopy]

I'm experiencing same problem as https://github.com/Microsoft/TypeScript/issues/9566 and per the last suggestion there, I'm reopening it with this new issue.

My problem has to do with how typescript manages ambient defs in a npm package I use using npm link.

I get a lot of compilation errors for @types definitions: Duplicate identifier 'export='.

These errors disappear altogether if instead of linking the module, I install it.

TypeScript Versions:
2.1.0-dev.20161028
2.0.6

Expected behavior:
Typescript doesn't import ambient definitions from linked modules. There shouldn't be a difference in behaviour between linked and installed packages.

Actual behavior:
Linked packages have @types included

[mhegazy]

@cortopy cab you share a sample, or a repro steps?

[cortopy]

These steps would reproduce the error:

• Angular 2 project with webpack 2 and typescript 2
• A module is linked using npm link (i.e.: not installed)
• Install lodash @types in both angular 2 parent project, and the npm linked dependency.

I'm not sure if this is about the lodash types only, but having read the issue that was closed, I suspect it's not just about lodash.

[linck]

I'm not sure if this is about the lodash types only, but having read the issue that was closed, I suspect it's not just about lodash.

@cortopy This is not only about loadash, occurs in any case. I have this problem with linked modules and @types too.

[linck]

@mhegazy You will replicate the problem, if you folow the Development environment (linked module) steps this repository https://github.com/linck/protontype-example.

[leviathanbadger]

Does anyone know of any workarounds to this that exist at the moment?

[linck]

@aboveyou00 I am using typings in linked module to test in development environment. Or delete @types folder of linked module. Or I just ignore duplicate identifier error. :(

[mhegazy]

thanks @linck. this is was very useful. I understand the problem now.

the issue is that there are really multiple packages on disk that are being loaded. so for lodash for instance there is:

• protontype/node_modules/@types/lodash
• protontype-example/node_modules/@types/lodash

which is correct since there are two node packages for lodash loaded as well at:

• protontype/node_modules/lodash
• protontype-example/node_modules/lodash

The source of the issue is that the declaration file for lodash is not authored correctly. it is authored as a global file, where two instances of the package can not co-exist. the correct fix here should be done on the lodash side in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/lodash/index.d.ts

You can workaround this issue by setting a path mapping into your tscofig.json as such:

"compilerOptions" {
     ....
    "baseUrl": "./",
    "paths": {
        "*": [ "node_modules/@types/*", "*"]
    }
   ...
}

What this does, is it tells the compiler, when resolving a module for instance lodash, anywhere, e.g. to first use the one in .\node_modules\@types\lodash first. this avoids loading multiple of these modules.

[linck]

Thanks very much @mhegazy! This config really solve the problem.
So, the problem is in the declaration file?

[mhegazy]

lodash should be fixed by https://github.com/DefinitelyTyped/DefinitelyTyped/pull/12361, we need to do the same to express and express-server-static as well.

[flyon]

just to be clear, as described above this is not an issue with any specific type definition. Any type definition that occurs in "types" in .tsconfig both in the main module and the module it npm link-ed will cause this problem. Suggested solution to ignore identical dupplicate type definitions seems like a good idea, though the workaround suggested by @mhegazy works for now.

[andy-ms]

Looks like a duplicate of #6496.

[SamVerschueren]

I'm experiencing the same issue with Firebase. The suggested solution does not work. Maybe because Firebase ships it's own type definitions? I tried adding "firebase": ["./node_modules/firebase"] to the paths option in tsconfig.json, but didn't work. Any ideas?

@andy-ms Not sure if it's the same issue. It looks like different error messages.