TypeScript: npm-linked modules (duplicates or not) are not working.

Re:

Search Terms

“typescript ignore npm linked dependencies”

Suggestion

I’d like for TypeScript to automatically work with npm linked 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 linked 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 linked 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 linked module, and this causes everything to work fine in the project, but then typings don’t work while working on the npm linked module. So to get back to developing the npm linked 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.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 13
Comments: 18 (2 by maintainers)

Most upvoted comments

you’ve found a solution or an workaround?

trickreich on Mar 13, 2020

@trusktr I have faced what I think is this same issue… I was able to work around it by providing a paths configuration for the module in question, and setting preserveSymlinks to true in tsconfig. Would be curious if this worked for you. Similar to the solution for webpack via the “resolve.alias” configuration property (comes up when one has multiple versions of react introduced via npm-link).

...
"preserveSymlinks": true,
    "baseUrl": ".",
    "paths": {
      "office-ui-fabric-react": ["node_modules/office-ui-fabric-react"]
    }

I am using office-ui-fabric react, and have an imported library with customized components.

shcarrico on Dec 10, 2019

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 of npm 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.md

I almost forgot: the workaround I’m using for the whole npm link mess: I don’t use npm link any more. Instead, I’m using a tiny script that I run manually to copy the contents of my package from project-b to project-a. Of course, for this to work correctly, I need to run npm install initially in project-a in order to have those dependencies of project-b correctly installed inside its dedicated node_modules folder, that can’t be flattened because project-a somehow uses those dependencies with different versions, too.

NicBright on Jun 18, 2020