New node_modules/@types lookup needs prodding to include node.d.ts in build

[yortus]

After reading @DanielRosenwasser's new blog post about the support in typescript@next for looking up type declarations directly from node_modules/@types/<libname>, I did as the post suggested and gave it a shot. It works great and I really love this huge improvement to the typings story.

However the first thing I saw when I ripped out all remaining triple-slash references was a lot of TS2307: can't find module 'fs' (and similar) errors for node builtin modules. So I added an explicit triple-slash reference to "node_modules/@types/node/index.d.ts" and those errors went away.

The same thing happened with mocha, where the compiler couldn't find 'describe' or 'it' until I added a triple-slash reference to node_modules/@types/mocha/index.d.ts.

I guess this is the expected behaviour, since these are ambient typings. But in the case of the very widely-used node.d.ts typings, is there a shortcut so I can just npm install @types/node and then import * as fs from 'fs'?

Otherwise I hope this caveat will be clearly documented when 2.0 rolls out, since adding the explicit refs to "node_modules/@types/node/index.d.ts" is not the most obvious thing given the new 'automatic' lookup system.

[mhegazy]

What version of tsc are you using? what is the structure of your folder? can you share your tsconfig.json?

here is my setup:

C:\test\sandbox5>type test.ts
import * as fs from "fs";
var x = fs.readFileSync("c:\\test\\a.ts").toString();
console.log(x);

C:\test\sandbox5>tsc --v
Version 1.9.0-dev.20160616-1.0

C:\test\sandbox5>ls node_modules\@types
[.]     [..]    [mocha] [node]

C:\test\sandbox5>tsc --listFiles test.ts
C:/Users/mhegazy/AppData/Roaming/npm/node_modules/typescript/lib/lib.d.ts
test.ts
C:/test/sandbox5/node_modules/@types/mocha/index.d.ts
C:/test/sandbox5/node_modules/@types/node/index.d.ts

[yortus]

This is using [email protected].

The project structure is like this:

<project root>
|-- package.json
|-- src/
    |-- index.ts            contains "console.log(process.env);"
    |-- tsconfig.json       contains "{"compilerOptions": {"listFiles": true}}"

Running tsc -p src results in TS2304: Cannot find name 'process'., and the file listing contains just [...]/typescript/lib/lib.d.ts and [...]/src/index.ts

Now if I move the files from src/ directly to the project root like so:

<project root>
|-- package.json
|-- index.ts            contains "console.log(process.env);"
|-- tsconfig.json       contains "{"compilerOptions": {"listFiles": true}}"

...then it compiles successfully and the file list also includes node_modules/@types/node/index.d.ts.

---

For context, some of our projects have multiple tsconfig.json files that build different parts with their own configurations. These are run in single build using a build script in the project's package.json, something like {"scripts": {"build": "tsc -p src && tsc -p test"}}

[mhegazy]

@RyanCavanaugh and @DanielRosenwasser we went back and forth on this, what is the recommendation here?

[yortus]

So after reading through the design notes (#9086), I added "typeRoots": ["../node_modules/@types"] to all the tsconfig.json files, and the project now compiles file, with no triple-slash references. Is that the recommendation for project structures like this?

[yortus]

IMO typeRoots is better than triple-slash references, but there does seem to be an inconsistency in type definition lookups.

For example, if I have import * as ts from 'typescript' in my-proj/src/nested/index.ts, it will walk up the spine until it resolves my-proj/node_modules/typescript/lib/typescript.d.ts.

Now if I add import * as fs from 'fs' to that my-proj/src/nested/index.ts file, I might expect silimar spine-walking behaviour to find my-proj/node_modules/@types/node/index.d.ts, which in fact does not happen.

[mhegazy]

you do not really need the typesRoot, you can just set types in your tsconfig.josn

"types" : [ "node", "mocha" ] 

[yortus]

OK, I missed that. But why isn't it walking the spine? #9086 says:

automatic type definition inclusion in compilations, include all "types" packages automatically

• value of --typesRoot if specified
• the first node_modules\@types walking the spine of the project

Which suggests our project should compile without needing either typesRoot or types, unless I'm misunderstanding 'walking the spine'.

[yortus]

Yep, "types": ["node","mocha"] works. Is "types" documented anywhere yet? (searching the repo for "types" is a bit hard). Is it basically a replacement for triple-slash references to ambient types? Living on the bleeding edge here... 😎

[mhegazy]

We are getting the documentation ready. should have something up in the coming weeks.

[yortus]

Great, thanks. So I guess the only question left is whether "types": ["node"] should be implicit/default. If that's a clear no (e.g. since projects may use npm for package/@types management, but are not necessarily node projects), then this can be closed.

EDIT: I'd also be interested to know why "types": ["node"] does not need to be specified if the source files are in the project root, but it does need need to be specified if they are in a subdirectory like src/. It seems inconsistent with, say, import * as ts from 'typescript', where the lookup succeeds regardless of whether the source file is directly in the project root or under src/.

[yortus]

Fixed by #10670.

[krvikash35]

I had related requirement. Is there any way to include all the types file name under typeroots directory, without typing name of all the types, like using any pattern.
Given below the expected behavior.

Existing syntax:
"typeRoots": ["node_modules/@types"],
"types": ["node", "express", "core" ]

Required syntax:
"typeRoots": ["node_modules/@types"],
"types": [ .* ]

[yortus]

@krvikash35 the behaviour I'm seeing now in the nightlies is that tsc automatically finds all types installed in node_modules/@types, without having to specify either typeRoots or types at all. Have you tried that?

[krvikash35]

I had tried with Version 2.0.2, will check it properly once.

[krvikash35]

Actually whatever you told is right..i dont have to mention even typeRoots or types name...but before this...i was using that ts with atom editor..so from command line it is working as expected but when i am using the same ts service as atom-plugin, i have to explicitly specify all types name ..