npm-linked modules (duplicates or not) are not working.
See original GitHub issueRe:
- https://github.com/Microsoft/TypeScript/issues/9566
- https://github.com/microsoft/TypeScript/issues/9771
- https://github.com/microsoft/TypeScript/issues/11916
- https://github.com/microsoft/TypeScript/issues/6496
Search Terms
“typescript ignore npm linked dependencies”
Suggestion
I’d like for TypeScript to automatically work with npm link
ed modules.
Use Cases
Prevents developers from wasting much time.
Examples
npm link
anything, and it just works.
Checklist
My suggestion meets these guidelines:
- This wouldn’t be a breaking change in existing TypeScript/JavaScript code
- This wouldn’t change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript’s Design Goals.
More details
I’m on TS v3.4.5
.
Even if a project’s npm link
ed module has the exact same version of a dependency,
> npm ls react
my-project@2.1.1 /Users/trusktr/src/my-project
├─┬ my-lib@2.0.0 -> /Users/trusktr/src/my-lib
│ └── react@16.8.6
└── react@16.8.6
TypeScript complains. For example:
[0] ERROR in /Users/trusktr/src/my-lib/node_modules/@types/react/index.d.ts(2963,13):
[0] TS2717: Subsequent property declarations must have the same type. Property 'view' must be of type 'SVGProps<SVGViewElement>', but here has type 'SVGProps<
SVGViewElement>'.
This is quite problematic, especially when needing to link 3, 4, or 5 modules at once during development, and especially more so when those linked modules have other npm link
ed modules. This issue grinds the dev experience to a halt. This npm link
workflow is commonplace in with plain JS projects using NPM.
I’ve tried all workarounds mentioned in the other four issues, but each workaround brings with it other problems, or just don’t work.
One workaround is to remove the duplicate dependency in the npm link
ed module, and this causes everything to work fine in the project, but then typings don’t work while working on the npm link
ed module. So to get back to developing the npm link
ed module, we need to reinstall the missing dependencies. Then when we switch back to the project we need to delete the dependencies in the linked package. Then when we switch back to the linked package… etc…
I believe that TypeScript should deeply embrace how npm link
works, and provide a built in solution so that TypeScript users never run into this again.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:10
- Comments:18 (2 by maintainers)
you’ve found a solution or an workaround?
I’m also having problems with “npm link” and TS, however for me, TS seems to not be able to work with the symlinked module at all …
Anyways, concerning this issue: I don’t think it’s TS responsibility to manage “duplicates”. The thing is, that the concept of “npm link” here already is flawed. It’s just not the same thing to have a package being regularly installed with “npm install” and having dependencies flattened correctly, compared with arbitrarily changing the structure of node_modules when doing “npm link”. For me, it is perfectly clear that TS just follows the usual node algorithm of including the nearest match (inside node_modules) … and duplicate types in this case are a problem, because it has to be assumed that the duplicated dependency ends as a duplicate at runtime … well and then it’s really two different types … e.g. try using
instanceof
operator on seemingly identical objects, whose constructor prototypes in fact are different objects.To summarize:
npm link
should be changed in a way to produce more realistic results matching what would be installed if the package had been regularly installed by means ofnpm install
. Just my two cents … Update: I just found this link, however I fear it will not help regarding the “duplicate dependencies” issue: https://github.com/npm/rfcs/blob/latest/accepted/0011-npm-link-changes.mdI almost forgot: the workaround I’m using for the whole
npm link
mess: I don’t usenpm link
any more. Instead, I’m using a tiny script that I run manually to copy the contents of my package fromproject-b
toproject-a
. Of course, for this to work correctly, I need to runnpm install
initially inproject-a
in order to have those dependencies ofproject-b
correctly installed inside its dedicatednode_modules
folder, that can’t be flattened becauseproject-a
somehow uses those dependencies with different versions, too.