[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.