Skip to content
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 · Fixed by guardian/dotcom-rendering#1881
Closed

Typescript@next and npm linked node_modules #11916

cortopy opened this issue Oct 28, 2016 · 12 comments · Fixed by guardian/dotcom-rendering#1881
Labels
Duplicate An existing issue was already created External Relates to another program, environment, or user action which we cannot control. @types Relates to working with .d.ts files (declaration/definition files) from DefinitelyTyped

Comments

@cortopy
Copy link

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
Copy link
Contributor

mhegazy commented Oct 28, 2016

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

@mhegazy mhegazy added the Needs More Info The issue still hasn't been fully clarified label Oct 28, 2016
@cortopy
Copy link
Author

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
Copy link

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
Copy link

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.

@leviathanbadger
Copy link
Contributor

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

@linck
Copy link

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
Copy link
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
Copy link

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 mhegazy added External Relates to another program, environment, or user action which we cannot control. @types Relates to working with .d.ts files (declaration/definition files) from DefinitelyTyped and removed Needs More Info The issue still hasn't been fully clarified labels Oct 30, 2016
mhegazy added a commit to DefinitelyTyped/DefinitelyTyped that referenced this issue Oct 31, 2016
* Fix microsoft/TypeScript#11916: Make lodash declarations a module

* Use lodash as a module

* Use lodash as  module

* Add headder
@mhegazy
Copy link
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
* 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
Copy link

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.

@mhegazy mhegazy assigned ghost Nov 9, 2016
@ghost
Copy link

ghost commented Nov 9, 2016

Looks like a duplicate of #6496.

@SamVerschueren
Copy link

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
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created External Relates to another program, environment, or user action which we cannot control. @types Relates to working with .d.ts files (declaration/definition files) from DefinitelyTyped
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants