New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typescript@next and npm linked node_modules #11916

Closed
cortopy opened this Issue Oct 28, 2016 · 12 comments

Comments

Projects
None yet
7 participants
@cortopy

cortopy commented Oct 28, 2016

I'm experiencing same problem as #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

This comment has been minimized.

Contributor

mhegazy commented Oct 28, 2016

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

@cortopy

This comment has been minimized.

cortopy commented Oct 29, 2016

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

This comment has been minimized.

linck commented Oct 29, 2016

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

This comment has been minimized.

linck commented Oct 29, 2016

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

@aboveyou00

This comment has been minimized.

Contributor

aboveyou00 commented Oct 29, 2016

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

@linck

This comment has been minimized.

linck commented Oct 29, 2016

@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

This comment has been minimized.

Contributor

mhegazy commented Oct 30, 2016

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

This comment has been minimized.

linck commented Oct 30, 2016

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

mhegazy added a commit to DefinitelyTyped/DefinitelyTyped that referenced this issue Oct 30, 2016

mhegazy added a commit to DefinitelyTyped/DefinitelyTyped that referenced this issue Oct 31, 2016

Fix Microsoft/TypeScript#11916: Make lodash a module (#12361)
* Fix Microsoft/TypeScript#11916: Make lodash declarations a module

* Use lodash as a module

* Use lodash as  module

* Add headder
@mhegazy

This comment has been minimized.

Contributor

mhegazy commented Oct 31, 2016

lodash should be fixed by DefinitelyTyped/DefinitelyTyped#12361, we need to do the same to express and express-server-static as well.

mhegazy added a commit to DefinitelyTyped/DefinitelyTyped that referenced this issue Nov 3, 2016

Fix for Microsoft/TypeScript#11916 (#12425)
* Switch express-serve-static-core to a module

* Add tsconfig to aws-serverless-express

* Switch aws-serverless-express to module

* Fix dangling pointer

* Fix wrong file name

* Add tsconfig.json

* switch seamless-immutable a module

* Add tsconfig.json

* use --strictNullChecks
@flyon

This comment has been minimized.

flyon commented Nov 9, 2016

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

This comment has been minimized.

Contributor

andy-ms commented Nov 9, 2016

Looks like a duplicate of #6496.

@SamVerschueren

This comment has been minimized.

SamVerschueren commented Jan 29, 2018

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.
screen shot 2018-01-28 at 19 19 31

@Microsoft Microsoft locked and limited conversation to collaborators Jul 3, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.