TypeScript: "Cannot find type definition file for 'node'." for 2.4.1

TypeScript Version: 2.4.1

Code

https://github.com/Mercateo/ws/tree/v2

Diff yarn.lock:

typescript@^2.3.4:
-  version "2.4.0"
-  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.4.0.tgz#aef5a8d404beba36ad339abf079ddddfffba86dd"
+  version "2.4.1"
+  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.4.1.tgz#c3ccb16ddaa0b2314de031e7e6fee89e5ba346bc"
$ yarn
$ npm run build

Expected behavior:

Compile.

Actual behavior:

ERROR in /Users/foo/Workspace/mercateo-ws/tsconfig.json
error TS2688: Cannot find type definition file for 'node'.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 33
  • Comments: 43 (8 by maintainers)

Commits related to this issue

Most upvoted comments

IMHO, new TypeScript releases should be tested against some simple Webpack projects that use ts-loader and ts-node (and also against DefinitelyTyped type definitions) before being published on npm.

TypeScript is not just github.com/Microsoft/TypeScript anymore, it became a whole ecosystem that needs to be kept in sync and tested

I’ve had this problem too using webpack and ts-loader when upgrading to TypeScript 2.4.1. In my case, I start webpack with the --watch option, and it printed a bunch of “Cannot find type definition file for x” the first time. After I made a change and the watcher detected it, the errors were gone.

I’ve managed to fix this by modifying the tsconfig.json file to include "types": [], which as stated in the documentation:

Specify “types”: [] to disable automatic inclusion of @types packages.

Keep in mind that automatic inclusion is only important if you’re using files with global declarations (as opposed to files declared as modules). If you use an import “foo” statement, for instance, TypeScript may still look through node_modules & node_modules/@types folders to find the foo package.

I’ve been debugging for the past 2.5 hours. Thank you for this issue. I was going insane.

Just made a tweak to ts-loader which seems to resolve the issue. Thought it was probably worth sharing here for any other project maintainers who’ve been bitten: https://github.com/TypeStrong/ts-loader/pull/566

I’m planning to release this as soon as I get a moment. FWIW I only heard about this today thanks to @donaldpipowitch helpful mention of me in this issue.

@donaldpipowitch, @stephen I have verified that both of these are building correctly with ts-loader@2.2.1. I’m closing this issue. Let us know if you are still seeing an issue after this.

Actually I see it as the responsibility of these downstream projects to be ready for TypeScript. vscode integrates to insiders which is published two weeks prior to the regular release of TypeScript. We in @dojo also started the work to accept 2.4 with the release of insiders. Other projects should do such integrations as well and ensure their semver is accurate. You can’t expect upstream projects to test every downstream project. It is illogical. I realise it effects folks, but you should be holding these downstream projects into account instead of projecting onto the TypeScript team. The TypeScript release cycle has been very predictable lately, which makes it a heck of a lot easier for us downstream projects.

The TypeScript team already goes over most of the DefinitelyTyped and there were quite a few patches made prior to the release of 2.4, though DefinitelyTyped is a community project.

I had similar problems with ts-node, but tsc -p was fine. Upgrading to v3.1.0 fixed the problem.

For TypeScript 2.4.2 if you already have some custom "typeRoots": [ ... ] defined into your tsconfig.json and in your package.json you also are including "@types/node" and you work with the standard node functions like require, you will receive the error: Cannot find type definition file for 'node'.

You need to add ./node_modules/@types/ to your typeRoots array! see docs

Backstory: I had this problem because I use WebStorm IDE which uses tsc to compile the project, and webpack to compile it separately. Suddenly after removing some 3rd party node packages that I had I started having the above error. Now it’s all good again.

On the other hand… I really struggled with mentioning you. I didn’t want to annoy you just because this problem could be related to ts-loader without really knowing it. (And because I’ve written you a lot lately about bugs^^)

Really don’t worry about it 😄

ts-loader v2.2.1 has now shipped and the issue should be resolved. Phew! It’s a little frustrating that the issue was actually picked up by the nightly test run but nothing actually came of reporting it here. But things slip through the cracks occasionally I guess; the issue is resolved now and that’s what matters most.

Foolishly I temporarily removed typescript@next from the ts-loader nightly build matrix whilst I was doing a release, forgot to add it back in and consequently forgot there was an issue that needed addressing. So that’s on me.

That said, I’m a little puzzled how something that was originally only showing up in TypeScript 2.5.x builds has ended up shipping with TypeScript 2.4.1.

Anyways… All’s well that end’s well. The problem is fixed now. 👍 🌷

Can I summarise this?

  • Some people have this problem with ts-node. Updating to v3.1.0 works.
  • Some people have this problem with ts-loader. (FYI @johnnyreilly.)
  • Other cases…?
  • Anyone who has this problem with tsc?

@skseth bumping ts-node seems to fix the issue for me too. I was on 3.0.6 -> 3.1.0 has done the trick.

It looks like this change https://github.com/TypeStrong/ts-node/pull/366 that they seem to be expecting in TypeScript 2.5 made it out early.

For what it’s worth, upgrading ts-node to the latest version seems to fix this issue for me.

Reverted typescript from version 2.4.1 to 2.2.2 in package.json: “typescript”: “2.2.2”, and works fine now