atom-typescript: [typescript2] - Doesn't recognize types installed by npm i @types/something

Just in case someone else falls into the same issue, here’s how you’d exclude node_modules and use node_modules/@types:

Before:

"exclude": [
    "node_modules"
]

After:

"exclude": [
    "node_modules",
    "!node_modules/@types"
]

If you simply remove the node_modules from the exclude array, Typescript will try to compile your code and everything else that’s in node_modules.

I’m working on an update to make atom-typescript behave exactly like running tsc from command line would (basically, by using tsserver that ships with the version of Typescript you have installed in your node_modules). That will address this and similar issues. If you feel it’s important to document the current behavior, I won’t say NO to a PR 😺

People here may already be aware of this, but this was new to me — here is where it’s documented that TypeScript automatically adds everything inside node_modules/@types:

https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types

(Note that because of the header on that page, you may have to scroll up a bit.)

Given that adding !node_modules/@types to exclude results in issue #1132 for me, I tried following that documentation and specifying typeRoots: ['./node_modules/@types'] instead, inside compilerOptions.

tsc still works, but unfortunately, atom-typescript does even worse then. Besides still failing to resolve any global variables (like describe and it), it also now outputs hundreds of false compilation errors like “Property status does not exist on type Response”, where Response is an interface we explicitly import. (It extends Express.Response, which we also explicitly import, in case that’s helpful.)

So at this point, it looks like my options are:

1. Add import {} from 'mocha', 'node', etc. anywhere we use globals.
2. Add !node_modules/@types to exclude, and hit issue #1132.
3. Add typeRoots: ['./node_modules/@types'] and hit more errors.

Clearly 1 is the least bad option, but it’s sad that it’s only needed for atom-typescript.

Please let me know if there’s any other info I can provide to help. Thank you again!

@jhm-ciberman, I’m glad you asked! #1166

I’m on the latest of everything pretty much (Atom-TypeScript 10.1.12, Atom 1.12.2, TypeScript 2.0.9, Node 6.9.1, etc.) and yes, this is an issue for me.

High-level repro: create a project with exclude: ['node_modules'] in tsconfig.json, npm install --save-dev @types/mocha, and write a new test/foo.ts file that references describe and it. VS Code doesn’t complain, it compiles fine w/ tsc, and runs fine w/ mocha --compilers ts:ts-node/register, but Atom-TypeScript complains that describe and it are unknown.

Adding '!node_modules/@types' to exclude like @ericmdantas suggested fixes this for me.

I actually don’t know (can’t explain) why only Atom-TypeScript fails here and others don’t also. The mocha typings certainly declare describe, it, etc. as globals, but I’m not quite sure how this typing gets picked up when mocha isn’t explicitly imported, and node_modules in general is excluded.

Alas, I think the biggest issue here is simply that Atom-TypeScript is differing from every other tool.

One can argue about if this is a bug or not. It definitely shows that atom-typescript diverges from the standard tsc compiler results.

There are multiple issues regarding more or less to the same problem: https://github.com/TypeStrong/atom-typescript/issues/1055

"exclude": [
    "node_modules"
]

You’re excluding all of node_modules, which is where it would store the types…?

My short term fix has been to leave out the excludes from my tsconfig, leaning on the defaults (since all I had in there was node_modules anyway):

The “exclude” property defaults to excluding the node_modules, bower_components, jspm_packages and <outDir> directories when not specified.

Then I’ve been able to define my custom types and typeRoots property without complaint from atom-typescript.

"types": ["node", "mocha", "whatwg-fetch", "enchanced-window"],
"typeRoots": ["./node_modules/@types", "./local-typings"]

Atom-typescript just seems to hate the interaction between typeRoots and excludes.

@guncha

You just need to specify types: [“mocha”, “node”] in your compilerOptions

Thanks, can this at least be documented in the readme, since as you noted, Typescript docs say Specify "types": [] to disable automatic inclusion of @types packages. If atom-typescript doesn’t behave like this, then it should at least be documented.

thanks

I ran into this same problem and have used import {} from 'mocha' in my code to resolve.

The silver lining is that you only need to do this once, so I have a typings.ts file and put this at the top along with other imports:

import {} from 'mocha';
// atom-typescript hack :(
// see https://github.com/TypeStrong/atom-typescript/issues/1054

And that seems to resolve it for all test files.

Thanks to @aseemk for listing the options.

Thanks for debugging. Yes, it seems that Typescript automatically adds everything inside node_modules/@types/* to the compilation context, but only if you haven’t specified any value for types in compilerOptions.

This is done in ts.createProgram while atom-typescript is using ts.createLanguageService to interface with the Typescript compiler. Makes me wonder if other editors have the same issue and why the Typescript people set it up this way.

Hey @guncha, thanks for the response. I want to clarify a few things:

You most certainly want to have node_modules in the exclude array

I’m sorry if this wasn’t clear: I am excluding it, and was not suggesting otherwise. I was talking about explicitly adding !node_modules/@types to exclude, as @ericmdantas suggested here:

https://github.com/TypeStrong/atom-typescript/issues/1054#issuecomment-240509189

1. Add import "jasmine" to any of your source files
2. Add jasmine to types array in compilerOptions

I understand I have these two options. And I completely get your reasoning — it makes sense. But the key issue to me is that I don’t need to do either of these for tsc, ts-node and VS Code. Why?

It’s possible that atom-typescript differs from the behavior you see with tsc, but you have to make sure that you’re using the exact same version of the compiler.

This might be a start! They indeed appear different.

I don’t have tsc installed globally at all; I only have it installed locally in my project via a local typescript dependency. It looks like Atom-TypeScript does this too, and the versions differ:

$ ./node_modules/.bin/tsc --version
Version 2.0.3

$  ~/.atom/packages/atom-typescript/node_modules/.bin/tsc --version
Version 2.1.0-dev.20161023

I manually set Atom-TypeScript to point to my 2.0.3 /full/path/to/node_modules/typescript/lib/typescriptServices.js , ran into issue #1124, so followed the loophole workaround. Unfortunately, if I remove !node_modules/@types from exclude, I still see this issue (of unrecognized describe and it errors). (And if I don’t remove !node_modules/@types from exclude, I still see issue #1132.)

Again, I’d just like to emphasize: I’d only like to understand why Atom-TypeScript doesn’t behave the same as tsc, ts-node, and VS Code. Thank you again.

Sorry, my bad. Tested it with the wrong packages. Looks like type definitions that provide globals like mocha, etc. are affected only.

The reason for atom-typescript’s different behavior is most likely the way it sets up the “Typescript Language Service”. I started to debug this issue once but haven’t found any time to do dig deeper.

Btw, I also experienced this with @types/node for e.g. require: Atom-TypeScript complains that require isn’t known, but no other tool does.

Thank you @ericmdantas for the tip! That fixes this for me too.

I was fighting with this behavior for months now, and I agree it feels like a bug since VS Code, tsc, and ts-node all work fine without having to explicitly include node_modules/@types.

Why does atom-typescript differ in behavior like this? Is there any specific reason?

Thanks for the great work on this plugin in general. I hope my comment doesn’t come across as ungrateful. =) Cheers.