Typescript: Allow ignoring certain TS suggestion-level diagnostic codes

Created on 3 Dec 2018  ·  7Comments  ·  Source: microsoft/TypeScript

Related to what was discussed in https://github.com/Microsoft/vscode/issues/61326.
Would provide more granularity to the settings introduced with https://github.com/Microsoft/vscode/pull/46590.

It might be useful to introduce a new setting to ignore certain suggestion diagnostic codes while still keeping suggestion diagnostics enabled, rather than having to disable them altogether.

What I'm proposing is to introduce 2 new settings, javascript.suggestionActions.ignoredCodes and typescript.suggestionActions.ignoredCodes. These would take a list of suggestion diagnostic codes that the user wants to ignore, given as a string of either comma- or space-separated code numbers.

Example:

{
  // ...

  "typescript.suggestionActions.enabled": true,
  "typescript.suggestionActions.ignoredCodes": "7043, 80006"

  // ...
}

This list would only be checked when a suggestion-level diagnostic is received, so including non-suggestion-level diagnostic codes in the list would have no effect (errors and messages would not be ignored).

In Discussion Suggestion

Most helpful comment

@mjbvz That's actually a better idea, adding those settings as compiler options instead.

The diagnostics setting could be extended to not only support a boolean, but to also accept an object with include and exclude arrays of codes. These 2 should be mutually exclusive, I don't see any situation where it would make sense to have both.

So for example, instead of fully disabling diagnostics as it can be done now, the user could do the following to enable all diagnostics except for some of them:

{
  "compilerOptions": {
    "diagnostics": {
      "exclude": [7043, 80006]
    }
  }
}

Or, similarly, only enable some of the diagnostics:

{
  "compilerOptions": {
    "diagnostics": {
      "include": [80003]
    }
  }
}

If it's decided to go that way, it might be worth assigning string identifiers to the diagnostic codes. Something like this would be much more readable:

{
  "compilerOptions": {
    "diagnostics": {
      "exclude": [
        "better-variable-type-may-be-inferred",
        "may-be-converted-to-async-function"
      ]
    }
  }
}

All 7 comments

@DanielRosenwasser We can implement the filtering on the VS Code side but should consider if we want a consistent story for TS.

@mjbvz That's actually a better idea, adding those settings as compiler options instead.

The diagnostics setting could be extended to not only support a boolean, but to also accept an object with include and exclude arrays of codes. These 2 should be mutually exclusive, I don't see any situation where it would make sense to have both.

So for example, instead of fully disabling diagnostics as it can be done now, the user could do the following to enable all diagnostics except for some of them:

{
  "compilerOptions": {
    "diagnostics": {
      "exclude": [7043, 80006]
    }
  }
}

Or, similarly, only enable some of the diagnostics:

{
  "compilerOptions": {
    "diagnostics": {
      "include": [80003]
    }
  }
}

If it's decided to go that way, it might be worth assigning string identifiers to the diagnostic codes. Something like this would be much more readable:

{
  "compilerOptions": {
    "diagnostics": {
      "exclude": [
        "better-variable-type-may-be-inferred",
        "may-be-converted-to-async-function"
      ]
    }
  }
}

@DanielRosenwasser

If it's decided to go that way, it might be worth assigning string identifiers to the diagnostic codes

I still agree with this sentiment~

may be we can add there a file exclusion for gradual migration (to e.g. strict mode) too? exclude those rules for a certain globbing pattern only.

want this feature too, mention that awesome-typescript-loader support this feature with the config item ignoreDiagnostics,I wish that is was supportted by typescript it self

Please provide a way to set these per file (or at least per file type). Some of the suggestions are great in TS files where they will be transpiled away, but should not be suggested for JS files which still need to run directly in older environments.

Was this page helpful?
0 / 5 - 0 ratings