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'.
Try using --traceResolution
.
We are having the same problem, but it only seems to surface when running mocha with --require ts-node/register
. Rolling back to 2.3.4 and will watch this issue.
Same issue here with ts-node/register. Fails to find all imported @types modules. I have reverted back to 2.3.4.
Ditto
I've been debugging for the past 2.5 hours. Thank you for this issue. I was going insane.
Having the same issue, but for several other type definition files including angular, angular-material, and more. Had to revert back to 2.3.4.
I think this is also an issue with ts-loader. 'tsc -p .' works fine but as of this upgrade, webpack
with ts-loader involved fails like this:
ts-loader: Using [email protected] and C:\Users\Jason\Repos\...\tsconfig.json
Hash: 193ab870329ba77c54cf
Version: webpack 2.5.0
Time: 18597ms
Asset Size Chunks Chunk Names
app.js 2.41 MB 0 [emitted] [big] main
app.js.map 2.88 MB 0 [emitted] main
...
[69] ./src/Components/Today/Today.tsx 10.6 kB {0} [built]
...
[380] ./src/Index.tsx 7.8 kB {0} [built]
+ 368 hidden modules
ERROR in C:\Users\Jason\Repos\...\tsconfig.json
error TS2688: Cannot find type definition file for 'node'.
ERROR in C:\Users\Jason\Repos\...\tsconfig.json
error TS2688: Cannot find type definition file for 'qrcode'.
(which is kinda weird because it looks like it built everything successfully before it errors out with this??)
Rolling back to 2.3.4 and the problem is gone.
similar issue: https://github.com/teppeis/typescript-simple/issues/82
Having similar issues with type definitions. (node, jquery...)
enforced typescript version 2.4.0 using npm-shrinkwrap as a workaround
build 27-Jun-2017 19:40:29 ERROR in ./src/main/resources/static/js/modules/InfoModule.ts
build 27-Jun-2017 19:40:29 (26,45): error TS2304: Cannot find name 'require'.
build 27-Jun-2017 19:40:29
build 27-Jun-2017 19:40:29 ERROR in ./src/main/resources/static/js/common/Helper.ts
build 27-Jun-2017 19:40:29 (4,17): error TS2503: Cannot find namespace 'Cookies'.
build 27-Jun-2017 19:40:29
.....
build 27-Jun-2017 19:40:29 ERROR in /var/......./webapp/tsconfig-prod.json
build 27-Jun-2017 19:40:29 error TS2688: Cannot find type definition file for 'handlebars'.
Having same issues with all of our type definitions, which are:
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'amcharts'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'fs-extra'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'handlebars'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'highlight.js'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'jasmine'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'jquery'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'lodash'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'marked'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'minimatch'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'node'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'shelljs'.
ERROR in [censored]/tsconfig.json
error TS2688: Cannot find type definition file for 'webpack-env'.
Same problem here.
I had similar problems with ts-node, but tsc -p was fine. Upgrading to v3.1.0 fixed the problem.
@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.
Can I summarise this?
ts-node
. Updating to v3.1.0
works.ts-loader
. (FYI @johnnyreilly.)tsc
?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鈥檙e 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 had this problem when upgrading to Typescript 2.4.1. I separate webpack with my project. it means that typescript has different module paths with @types file.
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
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.
It is not illogical. Rust does this: with every release of the language, they make sure that all the projects in their package manager still compile. This feature makes the language very robust and trustworthy.
I'm not saying this is the approach to follow by TypeScript, but certainly including some common setups among the tests would make troubleshooting backwards-incompatible problems much easier. It's just a matter of being able to provide an extensive breaking changes list.
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.
they make sure that all the projects in their package manager still compile
What do they do when it doesn't?
For the moment they just promise backwards compatibility.
(I must clarify that I'm not into Rust at all. I think it's a language with very interesting ideas and heard some talks on it and know a bit about its syntax, but that's about it.)
For the moment they just promise backwards compatibility.
Well, TypeScript doesn't between minor revisions, just patch revisions. So just making sure everything everywhere compiles wouldn't be valid.
2.4.0 was on June 6 and 2.4.1 was on June 27. I don"t see any major changes to module resolution in that span. More likely something about the way we deal with the host in the services layer changed.
It would nice to have a simple reproducible example that I could test out on the different TypeScript versions in that short time span to try and find out what happened. I can't reproduce this with just /// <reference types="node" />
in a file run by ts-node
. Nor with require("ts-node/register"); require("./a.ts");
.
The only releases in that span were:
2.4.0
2.5.0-dev.20170613
2.5.0-dev.20170614
2.5.0-dev.20170615
2.5.0-dev.20170616
2.5.0-dev.20170617
2.5.0-dev.20170618
2.5.0-dev.20170619
2.5.0-dev.20170621
2.5.0-dev.20170622
2.5.0-dev.20170623
2.5.0-dev.20170624
2.5.0-dev.20170625
2.5.0-dev.20170626
2.5.0-dev.20170627
2.4.1
Watching this... Have the same issue with @types/angular, using ts-loader with webpack
My project is using Node + Typescript + Webpack + ts-loader
+ ts-node
and I'm getting this problem when I updated to v2.4.1.
I fixed mine by switching to awesome-typescript-loader
. Done. :-) No more problems.
I can still use ts-node
with no problems.
@samwx - I'll likely release the ts-loader fix tonight.
@RyanCavanaugh / @DanielRosenwasser I've just realised that this issue is probably related to the failing ts-loader nightly builds issue I reported here:
https://github.com/Microsoft/TypeScript/issues/16609
Can you confirm?
@andy-ms here's an example with ts-loader
and webpack
: https://github.com/stephen/ts-test
from a set of travis runs with those releases, it looks like the issue began at 2.5.0-dev.20170615
: https://travis-ci.org/stephen/ts-test
FWIW I only heard about this today thanks to @donaldpipowitch helpful mention of me in this issue.
@johnnyreilly I could have written you earlier, but I didn't know ts-loader
was related to this issue. I just thought of it after others mentioned that they use ts-loader
, too.
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^^)
Regarding tooling support:
IMHO, new TypeScript releases should be tested against some simple Webpack projects that use ts-loader and ts-node
Actually I see it as the responsibility of these downstream projects to be ready for TypeScript.
IMHO it is not about the one or the other. As you already mentioned there are examples for both sides. We can just politely ask the maintainers of TypeScript to test against popular tools and/or maintainers of tools to test against nightly TypeScript versions.
IMHO some tools are so important that it would help if TypeScript team would help in some "official" way. E.g. they have "official" starters like this one, maybe they could have some sort of _curated tools_. Because...
I fixed mine by switching to awesome-typescript-loader. Done. :-) No more problems.
I really don't know how often I switched the loaders in the last, because one or the other had a bug, which the other didn't have at a specific time.
Or... (as mentioned in other issues like this one https://github.com/Microsoft/TypeScript/issues/16170)... I think it would be good to have an official dedicated tools team next to the core team just like the VS Code team works. (And because TypeScript already partly solves "tooling" problems - like noUnusedParameters
as some sort of linting.)
But this is part of a different discussion 馃憤
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. 馃憤 馃尫
@donaldpipowitch, @stephen I have verified that both of these are building correctly with [email protected]. I'm closing this issue. Let us know if you are still seeing an issue after this.
Thank you all for solving this.
@rbuckton Updated typescript
to 2.4.1 and ts-loader
to 2.2.1 and still the same =/
error TS6137: Cannot import type declaration files. Consider importing 'angular' instead of '@types/angular'.
The same project works fine on [email protected]
.
@samwx - I think this is a separate, unrelated change: https://github.com/Microsoft/TypeScript/issues/16472
@stephen Wow, that's true. Seems that typescript not supports imports like @types/...
anymore. Thank you!
Reverted typescript from version 2.4.1 to 2.2.2 in package.json:
"typescript": "2.2.2",
and works fine now
For what it's worth, upgrading ts-node
to the latest version seems to fix this issue for me.
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.
@serbanghita you are the MVP here. Just note that the ./node_modules/@types/
is relative to the directory where the tsconfig.json
file is
I have a TypeScript app which imports another TypeScript app and I am receiving error TS2688: Cannot find type definition file for 'node'.
from my imported module:
ode_modules/wire-webapp-cryptobox/dist/typings/wire-webapp-cryptobox.d.ts(18,23): error TS2688: Cannot find type definition file for 'node'.
I checked wire-webapp-cryptobox.d.ts(18,23)
and it's this statement:
/// <reference types="node" />
The config of "wire-webapp-cryptobox.d.ts" looks as follows:
{
"compilerOptions": {
"declaration": false,
"lib": ["es7", "dom"],
"module": "commonjs",
"moduleResolution": "node",
"noEmitOnError": true,
"noImplicitAny": false,
"noImplicitReturns": true,
"removeComments": true,
"sourceMap": false,
"target": "es5"
},
"exclude": [
"bower_components",
"node_modules",
"typings/browser",
"typings/browser.d.ts"
]
}
Can you tell me where I need to set typeRoots
to fix the error?
@bennyn TypeScript won't be looking at any tsconfig.json
in your node_modules
-- it will just use your own. Try checking the output of --traceResolution
to see where it's looking. It should look in your node_modules
for the dependency, but it's possible that your own tsconfig.json
changed this behavior.
I got this error with javascript triple slash reference too
I try to reference the global node module. Is it not possible?
Most helpful comment
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