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

[ericmdantas]

First of, amazing job with this package.

So, I have this new project that I'm using typescript@2 and I decided to give @types a shot too.

I have this test file that depends on jasmine, so I installed the types for it by running npm i --save-dev @types/jasmine. It has the following content:

// my_app_test.ts

describe('my-app', () => {
  console.log('yo');
});

If I run tsc, it compiles just fine, no warnings, no errors - nothing. But, Atom keeps telling me Cannot find name 'describe'.. So I figured it should be related to atom-typescript.

Info

• os: windows 7, 64bits
• atom: 1.9.8
• atom-typescript: 10.1.6
• tsconfig:

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "noImplicitAny": true,
        "sourceMap": false
    },
    "exclude": [
        "node_modules"
    ]
}

Thanks!

[DanielJoyce]

"exclude": [
    "node_modules"
]

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

[ericmdantas]

Welp, that makes sense. Thanks, @DanielJoyce!

[ericmdantas]

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.

[iamolivinius]

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:
#1055

[aseemk]

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.

[iamolivinius]

Is this still a thing? I'm using version 10.1.9 without any issues any more.

[aseemk]

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.

[aseemk]

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.

[iamolivinius]

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.

[aseemk]

Thanks! I hope we can find the answer.

One note/update: unfortunately, adding !node_modules/@types to exclude for some reason (??) now makes Atom-TypeScript think that my test files aren't in the compilation context: #1132

This is happening consistently for me. And I just realized that when this happens, Atom-TypeScript doesn't catch any compilation issues in that file anymore.

So... maybe I'll revert adding !node_modues/@types to exclude and instead import {} from 'mocha' in the test files. I wouldn't want to do this for Node globals in every file though...

[guncha]

You most certainly want to have node_modules in the exclude array, in fact, it should be the default behavior if nothing else is specified. 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. I will happily review and accept pull requests that address issues like this.

Now, to get the global typings like jasmine to work, you have two options:

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

Typescript builds a compilation context before it can type check anything. It starts with all entry files specified with files or include options in tsconfig.json minus anything matching exclude and it adds all dependencies that are explicitly required from those files. This is why option 1 works. Typescript also resolves the modules you've specified with types in option 2 and adds them to the compilation context. This is the preferred way to add global types like jasmine and node.

[aseemk]

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:

#1054 (comment)

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.

[guncha]

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.

[aseemk]

Nice find! Would it be worth re-opening this issue to track this difference now?

[aseemk]

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 File "not included in the TypeScript compilation context" error on valid tsconfig? #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!

[guncha]

You just need to specify types: ["mocha", "node"] in your compilerOptions. This will ensure that tsc and atom-typescript behave the same way due to the behavior I described above. I haven't seen any mention of it in the docs either.

[aseemk]

Good idea, thanks.

Unfortunately, when I do that, I again get new (but different) errors. These errors don't seem to be related to globals. I sunk an hour debugging the errors to see if they might be legit, but again, tsc, ts-node and VS Code all compile fine.

This is unfortunately quite exhausting. I wish I knew how to make atom-typescript "just work". I realize me saying this isn't helpful or constructive. Again, if there's any other info I could provide...

[swinc]

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.

[code-tree]

@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

[guncha]

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 😺

[code-tree]

Sounds good, thanks. I've added a PR in the meantime.

[MaxDesiatov]

I wasn't able to work around this bug with atom-typescript, tried all "include", "exclude", "typeRoots" combinations imaginable and all combinations I've found in these GitHub issues, nothing works with atom-typescript, while everything works perfectly in command-line with tsc. Abandoning atom-typescript for Visual Studio Code (where everything works out of the box) because of this. Hope it gets fixed soon.

[swinc]

@explicitcall another option is "lib": "["DOM", "es6"] if you're targeting es5. Depends on the exact issue you are having.

[MaxDesiatov]

it doesn't solve the issue that atom-typescript behaves differently than command-line tsc invocation with the same tsconfig.json

[jhm-ciberman]

@guncha any update with the Fix?

[merrywhether]

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 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]

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