Angular-cli: @types/node type definitions interfere with app code (e.g. setTimeout)

[tomwanzek]

Please provide us with the following information:

1. OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

_Windows 10_

1. Versions. Please run ng --version. If there's nothing outputted, please run
   in a Terminal: node --version and paste the result here:

_angular-cli: 1.0.0-beta.14
node: 6.5.0
os: win32 x64_

1. Repro steps. Was this an app that wasn't created using the CLI? What change did you
   do on your code? etc.

Assume your component source code includes let timerID: number = setTimeout(...);. In previous versions of the cli (webpack.8), this code compiled without errors. As of beta.14, "@types/node" definitions seem to be included into the compilation scope. I suspect, that is coincidental based on a development dependency of the cli.

As a result, the compiler (and the IDE) considers setTimeout(...) to return a NodeJS.Timer object. The result is a type mismatch error.

While using window.setTimeout(...) instead, serves as a workaround, it seems the node definitions should be kept out of the client source code compile context?

1. The log given by the failure. Normally this include a stack trace and some
   more information.
2. Mention any other details that might be useful.

---

Thanks! We'll be in touch soon.

[filipesilva]

Your guess is quite right: we have defined "typeRoots: [ "../node_modules/@types/" ] in tsconfig.json, which means that it looks there for typings.

Recently protractor added @types/node to it's dependencies.

npm3 deduping sees that there's no conflict for @types/node so it gets moved from node_modules/protractor/node_modules/@types/node to node_modules/@types/node, together with all the other project @types/*.

I don't have a solution for you at the moment really but I recognize this is a problem. Not sure the CLI itself can solve it though.

[tomwanzek]

@filipesilva first off thanks for all the hard work on this marvel of a developer tool 👍 .

When I encountered the issue, I did not have time to dig deeper into which dependency had introduced the node type definitions. Thx to the pointer to protractor.

I did not have a chance to play around with the tsconfig.json for the app source code. Possibly it could be as simple as adding an explicit exclude for the @types/node. If so, it might be something the update the new project blueprint with.

When I have a second, I will double-check and update here.

[tomwanzek]

Yeah, as I thought initially the exclude property of the tsconfig.json has no effect.

However, while the typeRoots property of the tsconfig.json (for src) correctly points to ..\node_modules\@types, I still kind of fail to see, why the node typings end up in the compilation scope. Should the globals from node not only get into the compilation scope, if at least one file \\\ <reference types="node" /> them within the scope? Protractor should play no part in that within the src directory.

It is nevertheless an issue that similarly affects the compilation scope within the e2e test directory.

[niklas-dahl]

I am experiencing a simmilar error during ng serve when installing @types/mocha:

[ERROR in [default] C:\Users\user\project\node_modules\@types\jasmine\index.d.ts:9:17
Duplicate identifier 'describe'.

ERROR in [default] C:\Users\user\project\node_modules\@types\jasmine\index.d.ts:11:17
Duplicate identifier 'xdescribe'.

ERROR in [default] C:\Users\user\project\node_modules\@types\jasmine\index.d.ts:13:17
Duplicate identifier 'it'.

ERROR in [default] C:\Users\user\project\node_modules\@types\jasmine\index.d.ts:15:17
Duplicate identifier 'xit'.

ERROR in [default] C:\Users\user\project\node_modules\@types\mocha\index.d.ts:33:12
Duplicate identifier 'describe'.

ERROR in [default] C:\Users\user\project\node_modules\@types\mocha\index.d.ts:34:12
Duplicate identifier 'xdescribe'.

ERROR in [default] C:\Users\user\project\node_modules\@types\mocha\index.d.ts:39:12
Duplicate identifier 'it'.

ERROR in [default] C:\Users\user\project\node_modules\@types\mocha\index.d.ts:40:12
Duplicate identifier 'xit'.](url)

I use mocha for unit testing my server side code, but the mocha typings shoulnt be included in any way in the client build.

[filipesilva]

In npm3 there is a process called deduping where it de-duplicates node modules. Whenever it is safe, modules "bubble up" to the top level, which is why with npm3 you usually end up with a lot more stuff directly under node_modules/ but overall less modules compared to npm2.

What happened here is that the @types/node module bubbled up from node_modules/protractor/node_modules/ to node_modules/, and thus ended up in the directory we specify as root for our typings.

To get around this, you can manually list which typings you want to use in tsconfig:
https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Compiler%20Options.md

    "typeRoots": [
      "../node_modules/@types"
    ],
    "types": [
      "jasmine",
      "node"
    ]

@tomwanzek In case you don't want to use the node typings, you'll have to add declare var require: any; to src/typings.d.ts because we still use require as part of our template inlining process.

[tomwanzek]

@filipesilva Thanks a lot... for all the hard work in general :+1: and the update above in particular. Will test out your suggestions asap.

In the meantime thanks for angular-cli!

[tobihagemann]

Is it possible that this issue has resurfaced with Angular 7.2.0? It looks like that @types/node has been added as a dependency through @schematics/update (I guess, by the addition of @types/webpack-sources).

[sam-s4s]

Yes, I've found my way here with the same issue...

The tree of dependency is now...

@angular-devkit/build-angular
license-webpack-plugin
@types/webpack-sources
@types/node

[saslani]

@sam-s4s and @tobihagemann did you find a solution to this? My code works locally (mac Mojave) but fails in Debian 9. (I am using Vagrant to spin up Debian 9). When I run npm install on Debian I get the following error (just pointing out that I am new to Angular anyway)

npm ERR! path /vagrant/XYZ/node_modules/@types/webpack-sources/node_modules/source-map/package.json.2705805710
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open '/vagrant/XYZ/node_modules/@types/webpack-sources/node_modules/source-map/package.json.2705805710'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/vagrant/.npm/_logs/2019-05-22T17_13_15_099Z-debug.log

I am using Angular 7, node 12.2.0, npm 6.9.0

"dependencies": {
    "@angular/animations": "7.2.15",
    "@angular/cli": "7.3.9",
.
.
.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}