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

[trusktr]

Re:

• Typescript@next and npm linked node_modules #9566
• Conflict between several @types package #9771
• Typescript@next and npm linked node_modules #11916
• Duplicate type declarations with npm link #6496

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.

[trusktr]

I think the solution involves TypeScript treating linked modules as if they are not linked modules (if it doesn't already), and use a top-down module resolution (file traversal) so that it will pick the top-most libraries from which to get dependencies (types) from.

If there's a dependency constraint that can not be matched, then it will use a lower-in-the-tree module (just like NPM) to get types from, and get those types only for the package the needs those types from that specific version (regardless if the types are .d.ts or .ts).

This would essentially work the same way as NPM's flattening approach, where it flattens everything unless there are dependency forks (i.e. version ranges can't be satisfied for two or more packages that need incompatible versions of the same lib), except TypeScript won't do any flattening, TypeScript will simply trust the flattened structure that NPM will already have put in place.

[trusktr]

I meant to put I'm on TS v3.4.5 up there. Edited.

[trusktr]

The workaround I mentioned, deleting the dependency in the linked module, doesn't work in this case (I thought it did before, but, now I'm not sure). Now I get

[1] ../my-lib/node_modules/@material-ui/core/styles/withStyles.d.ts:1:24 - error TS2307: Cannot find module 'react'.
[1]
[1] 1 import * as React from 'react';

As in my suggestion, if TypeScript were to treat the linked module as if it were not linked, and continued to traverse up the tree in the main project where tsc is running from, then it would find react higher up (as a dependency of the project that has the linked module). This is how NPM module resolution works at runtime if we delete the dependency in the linked module. TS is not doing the same at compile time.

[trusktr]

However, because we don't want to delete the dependencies in the linked modules (so that we can also go and work locally inside the linked modules when making changes to those modules), this is why I suggested a top-down approach which should ultimately result in the same modules being resolved as with NPM's flattening when no modules are linked).

Note, when modules are linked, NPM's resolution is bottom-up, and that can introduce other problems, which is something I wish NPM would fix.

[trusktr]

EDIT: The workaround does work: I was deleting react instead of @types/react in the linked module. If I delete only @types/react in the linked module, then the project uses the one at the root of node_modules.

The top-down idea still holds though, I think an approach like that would work.

[trusktr]

I just experienced issues again today. As an example, I have a project-a which depends on project-b. Both project-a and project-b depend on the same version of react.

In project-b, I ran

npm install
npm link
npm run build # generates a dist/ folder

After doing this project-b contains react in its node_modules.

Then in project-a I ran

npm install # installs project-b (and its dependencies) from NPM

Now project-a contains both project-b and react in its node_modules. The folders look like this:

project-a
    node_modules
        react
        project-b

Now I want to work with a local version of project-b which I'm currently working on, so:

npm link project-b # link the local version of project-b into project-a

Now project-a contains react as well as a linked version of project-b. Remember that project-b also contains react. So now, the folder structure of project-a's node_modules looks like this:

project-a
    node_modules
        react
        project-b (symlinked)
            node_modules
                react

Now what will happen is that TypeScript will give errors like the following:

Details

[1] ../project-b/node_modules/@types/react/index.d.ts:2997:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'rect' must be of type 'SVGProps<SVGRectElement>', but here has type 'SVGProps<SVGRectElement>'.
[1] 
[1] 2997             rect: React.SVGProps<SVGRectElement>;
[1]                  ~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:2998:13
[1]     2998             rect: React.SVGProps<SVGRectElement>;
[1]                      ~~~~
[1]     'rect' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:2998:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'stop' must be of type 'SVGProps<SVGStopElement>', but here has type 'SVGProps<SVGStopElement>'.
[1] 
[1] 2998             stop: React.SVGProps<SVGStopElement>;
[1]                  ~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:2999:13
[1]     2999             stop: React.SVGProps<SVGStopElement>;
[1]                      ~~~~
[1]     'stop' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:2999:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'switch' must be of type 'SVGProps<SVGSwitchElement>', but here has type 'SVGProps<SVGSwitchElement>'.
[1] 
[1] 2999             switch: React.SVGProps<SVGSwitchElement>;
[1]                  ~~~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3000:13
[1]     3000             switch: React.SVGProps<SVGSwitchElement>;
[1]                      ~~~~~~
[1]     'switch' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:3000:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'symbol' must be of type 'SVGProps<SVGSymbolElement>', but here has type 'SVGProps<SVGSymbolElement>'.
[1] 
[1] 3000             symbol: React.SVGProps<SVGSymbolElement>;
[1]                  ~~~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3001:13
[1]     3001             symbol: React.SVGProps<SVGSymbolElement>;
[1]                      ~~~~~~
[1]     'symbol' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:3001:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'text' must be of type 'SVGProps<SVGTextElement>', but here has type 'SVGProps<SVGTextElement>'.
[1] 
[1] 3001             text: React.SVGProps<SVGTextElement>;
[1]                  ~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3002:13
[1]     3002             text: React.SVGProps<SVGTextElement>;
[1]                      ~~~~
[1]     'text' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:3002:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'textPath' must be of type 'SVGProps<SVGTextPathElement>', but here has type 'SVGProps<SVGTextPathElement>'.
[1] 
[1] 3002             textPath: React.SVGProps<SVGTextPathElement>;
[1]                  ~~~~~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3003:13
[1]     3003             textPath: React.SVGProps<SVGTextPathElement>;
[1]                      ~~~~~~~~
[1]     'textPath' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:3003:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'tspan' must be of type 'SVGProps<SVGTSpanElement>', but here has type 'SVGProps<SVGTSpanElement>'.
[1] 
[1] 3003             tspan: React.SVGProps<SVGTSpanElement>;
[1]                  ~~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3004:13
[1]     3004             tspan: React.SVGProps<SVGTSpanElement>;
[1]                      ~~~~~
[1]     'tspan' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:3004:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'use' must be of type 'SVGProps<SVGUseElement>', but here has type 'SVGProps<SVGUseElement>'.
[1] 
[1] 3004             use: React.SVGProps<SVGUseElement>;
[1]                  ~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3005:13
[1]     3005             use: React.SVGProps<SVGUseElement>;
[1]                      ~~~
[1]     'use' was also declared here.
[1] 
[1] ../project-b/node_modules/@types/react/index.d.ts:3005:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'view' must be of type 'SVGProps<SVGViewElement>', but here has type 'SVGProps<SVGViewElement>'.
[1] 
[1] 3005             view: React.SVGProps<SVGViewElement>;
[1]                  ~~~~
[1] 
[1]   node_modules/@types/react/index.d.ts:3006:13
[1]     3006             view: React.SVGProps<SVGViewElement>;
[1]                      ~~~~
[1]     'view' was also declared here.
[1] 

So it appears that when TypeScript is looking up type definitions, it picks up the ones in project-a's version of react and in project-b's version of react, where both react's even have the same version number.

The problem can be exacerbated when linking more than one package, and even more so when for example linking a project-c to project-b, linking project-b to project-a, and linking project-c to project-a.

The npm link workflow is a common workflow in many projects. However, I haven't used too much in the context of TypeScript projects until the last year where all my projects have been in TypeScript, not plain JavaScript.

solution thoughts:

I believe TypeScript should default to picking the types from a package which is the top-most package in node_modules.

So, from perspective of project-a, when TypeScript is compiling project-a code, it'd be nice if it chose the top-most react, and ignore the one in project-b's node_modules.

[trusktr]

I'm struggling with this. This makes npm link workflows very difficult and time consuming.

Can I ask, have any of you used npm link workflows in TypeScript projects? Have you had any issues?

[trusktr]

Is this a regression of #16274 ?

[sheetalkamat]

Are you using typescript@3.5? I think #31541 should have fixed this. If not can you create sample repro so we can investigate this.

[trusktr]

Alright, I'll report back when I give it a go.