16

I have a TypeScript project that builds and runs, but I have a ton of build errors that all seem to stem from one error:

TS4090: (TS) Conflicting definitions for 'node' found at 'C:/[projectpath]/node_modules/@types/node/index.d.ts' and 'C:/[user path to Microsoft]/Typescript/3.1/node_modules/@types/node/index.d.ts'. Consider installing a specific version of this library to resolve the conflict.

I don't understand the bit about "installing a specific version of this library". I'm not certain why two versions are being found to begin with.

My app has a tsconfig.json file located in the ClientApp folder. It contains the following:

{
  "compileOnSave": false,
  "compilerOptions": {
    "module": "esnext",
    "skipLibCheck": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "sourceMap": true,
    "target": "es2015",
    "lib": [
        "es2016",
        "es2017",
      "dom"
    ],
    "moduleResolution": "node",
    "allowJs": true,
    "baseUrl": "src"
  },
  "include": [
    "./src/**/*.ts",
    "./test/**/*.ts",
    "./custom_typings/**/*.d.ts"
  ],
    "atom": {
        "rewriteTsconfig": false
    },
    "typeAcquisition": {"enable": false}
}

I added the typeAcquisition recently based on comments on other posts relating to this -- but it had no affect.

What do I need to do to "install a specific version of this library"?

Environment

The project targets .NetCore 2.2. The project contains WebAPI Controllers that serve up backend data as well as a ClientApp folder that contains a SPA UI created with Aurelia. I use WebPack to build the SPA application.

Errors

enter image description here

RHarris
  • 10,641
  • 13
  • 59
  • 103
  • 2
    try deleting the node_modules folder _and_ deleting your `package-lock.json` file inside your project and removing `@types/node` from `package.json`. Re-install . your node-modules with `npm i` and re-install your node types as a dev dependency with `npm i @types/node --save-dev` – Michael Sorensen Jun 20 '19 at 16:58
  • Unfortunately, that didn't fix anything. Still getting all the same TS errors in VS2017 – RHarris Jun 20 '19 at 18:02
  • 1
    I think tracing the module resolution might help you track it down. If you add `"traceResolution": true` to `"compilerOptions"` you'll get a trace of how TS is determining what module to use. [This section of the TS documentation](https://www.typescriptlang.org/docs/handbook/module-resolution.html#tracing-module-resolution), specifically the **Things to look out for** subsection, should help you make heads-or-tails of the output. – YardGnomeNinja Jun 21 '19 at 15:15
  • @YardGnomeNinja - hey, I think you just helped me over on the Aurelia Discourse forum -- are you tracking me (jk) :) I added `traceResolution` as you suggested -- where do I see the output? I don't see anything in the build output and I can't seem to run `tsc` from the command window. – RHarris Jun 21 '19 at 17:42
  • I don't think this flag (`traceResolution`) is supported by MSBuild: https://apimirror.com/typescript/handbook/compiler-options-in-msbuild. So you can't use it in this case – Mr Patience Jul 25 '21 at 11:53

6 Answers6

14

I fixed this by moving

"@types/node": "^10.11.6"

from devDependencies to the peerDependencies in my package.json file

"peerDependencies": {
    "@types/node": "^10.11.6"
  },
4imble
  • 13,979
  • 15
  • 70
  • 125
  • 5
    Could you provide more information about the reasoning of moving it? Or a link explaining it? – VinGarcia Feb 21 '20 at 17:51
  • Document is your friend: https://nodejs.org/ru/blog/npm/peer-dependencies/ – NordicShaw Mar 02 '20 at 11:30
  • @NordicShaw That documents what peer dependencies are. But why is that appropriate to use here? I've never seen a `@types/` package as a `peerDependency` before. – Peeja Jun 28 '23 at 19:17
12

For me, I fixed it by change/add "typeRoots" in compilerOptions (tsconfig.json)

"compilerOptions": {
        ....
         "typeRoots": [
            "node_modules/@types"
        ]
        ....
}
Mahrez BenHamad
  • 1,791
  • 1
  • 15
  • 21
0

For me, it was karma.config file, which was causing the issues.

After I have deleted some of the types in the package.json, I managed to reduce the number of errors and there was only one - between signalr and karma.

Screenshot of error

For some reason I had a .js, not .ts karma config.
After I had switched to the correct configuration and restarted the VS, the problem was resolved.

It have needed some version of node as there was a require function used.
My theory is, Visual Studio automatically included types for accessible version of node, as a part of linting functionality for JavaScript.
But then, after it compiled typescript, another version of types for node was included - conflicting with the one already present.

None of the operations in tsconfig.json file would have resolved the issue, as the conflict was present between node types for TS and node types for JS.

Mr Patience
  • 1,564
  • 16
  • 30
0

In my case, the packages electron and node-opcua were using different @types/node versions, resulting in the "TS4090: (TS) Conflicting definitions for 'node" error.

I had successfully fixed that error by providing manually a version for @types/node in my peerDependencies as pointed out in the error, however after installing the project elswhere this version changed and it turned out to be a bad idea. So I added npm dedupe as a posinstall script in my package.json and it works fine.
As the documentation states, it browses through the whole dependency tree and removes duplicated packages by moving them up the tree.

FrelonGuepe
  • 31
  • 3
0

If you import mongoose in 2 different files, make sure to use the same import eg. use

const mongoose = require("mongoose");

in both files

Johnson
  • 55
  • 7
-1

Fixed that by

rm -rf node_modules
rm package-lock.json
npm i
chek
  • 31
  • 2
  • 6