atom/ide-typescript

Suppress certain warnings for JavaScript

jbrew138 opened this issue · 10 comments

After updating to 0.8.0 I'm really happy with the new language server and expanded diagnostics, but I'm getting a type of warning while working in JavaScript specific to TypeScript.

For example:

const nodemailer = require('nodemailer');

The base package for Nodemailer doesn't have an implementation for TypeScript, which I assume triggers this warning:

Could not find a declaration file for module 'nodemailer'. 'c:/###/node_modules/nodemailer/lib/nodemailer.js' implicitly has an 'any' type.
Try npm install @types/nodemailer if it exists or add a new declaration (.d.ts) file containing `declare module 'nodemailer';

This occurs with several packages including ffmpeg-static, child-process-promise, and others.

I'm not aware of any way to set up configuration for the new language server, but adding a way to suppress specific warnings like these would be really helpful, similar to eslint's config. Or at the very least, maybe a simple filter before the linter warnings are consumed?

Agreed... this is generating a lot of irrelevant warnings, which is frustrating because it's going to train me to mentally ignore warnings going forward, and that's not good! Would appreciate it if anyone knows of a config setting to ignore declaration file warnings.

@jbrew138 Actually, this might be as simple as unchecking "Diagnostics Enabled" in the ide-typescript settings, or modifying your config.cson file like so:

- "ide-typescript": {}
+ "ide-typescript":
+   diagnosticsEnabled: false

If you're working solely in Javascript and using linter-eslint, you probably don't need those diagnostics in the first place.

You can probably disable this at a more granular level by creating a jsconfig.json file in your project root with the right option. I think perhaps noResolve might be the one.

https://code.visualstudio.com/docs/languages/jsconfig

Alternatively setting "checkJs": false will turn off all type-inference of JavaScript files while leaving other syntax checking on.

@damieng This may be a dumb question, but does jsconfig.json work for Atom as well as Visual Studio? Is Atom's ide-typescript using the same language service?

They are using different language servers but ultimately both of them use the TypeScript server at the lower levels which honors jsconfig.json and tsconfig.json

@mattdiamond I've mostly been relying on the linting from ide-typescript because I was having performance issues while using linter-eslint. Using Theia Language Server then fixed the performance issues I saw with SourceGraph, both for linting and autocomplete, so I hesitate to go back.

@damieng Creating a jsconfig.json file in the project root and toggling the checkJs and noResolve flags is definitely picked up in Atom. It wouldn't pick up tsconfig.json, likely because all my files are JavaScript anyway.

The default for checkJs seemed to be false. Setting noResolve to true only suppressed a couple This may be converted to async warnings (but not all of them). The declaration file warnings are still there.

Adding jsconfig.json also triggered File is a CommonJS module; it may be converted to an ES6 module. warnings when using require(), but I'm working with Node so that's another example.

Looking over at the Theia repository, they have a file called tsconfig.settings.json that has some specific flags: declaration, declarationMap, module, moduleResolution but I can't get them to be recognized from jsconfig.json. It looks like they use VSCode, so it's a different environment.

I managed to silence the "Could not find a declaration file" warnings by setting suppressImplicitAnyIndexErrors instead. Here's my jsconfig.json:

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "suppressImplicitAnyIndexErrors": true
  }
}

... No, false alarm. I think my language server took a minute to boot. I still see "Could not find a declaration file" warnings with suppressImplicitAnyIndexErrors and noResolve.

I've opened #160 which bumps the Typescript Server version we are using so it will download @types/${packageName} automatically when available but this will still show up if there are no types packages.

I've confirmed the same behavior shows in VSCode (although the UI for the warning is much more subtle).

The only way I've found to disable this warning is to use strict: true and maxNodeModuleJsDepth: 0.

jsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "maxNodeModuleJsDepth": 0
  }
}

However it should be noted that this disables everything (warnings, annotations, suggestions...) in modules which is not ideal.

I somehow hacked around this issue for a particular dependency by

  1. adding an empty file jsconfig.json to the my source folder, hoping that it would make ide-typescript behave as VSCode is documented to behave and
  2. adding a file lib.d.ts to the same folder with these contents:
declare module 'name-of-dependency';

(I appended both filenames to my .git/info/exclude so that I wouldn't have to bother my collaborators with my choice of editor)

When I'd named the empty file tsconfig.json, the static analysis did not seem to take the .d.ts file into account when reporting on the other source files in the folder.