Allow ignoring certain TS suggestion-level diagnostic codes

[jsayol]

Related to what was discussed in microsoft/vscode#61326.
Would provide more granularity to the settings introduced with microsoft/vscode#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).

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Allow diagnostics messages to have markdown (or formatted text) content (#54272)
• Add way for extensions to signal that diagnostics are actively being computed but have not been returned yet (#54273)
• Allow MarkedStrings in Diagnostics (#20232)

[mjbvz]

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

[jsayol]

@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"
      ]
    }
  }
}

[weswigham]

@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~

[OneCyrus]

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.

[javaxiu]

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

[michens]

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.

[orassayag]

Is there any progress with this feature? I would like to remove some VSCode suggestions.
I would like an option to remove this:

[karlhorky]

Input from the extension ecosystem: this would help with implementing features where a TypeScript language service plugin wants to allow configuration of ignoring certain errors:

frigus02/typescript-sql-tagged-template-plugin#11 (comment)

[tomaszs]

What is the status?

[wenfangdu]

Something like this would be great:

Ref: https://github.com/typescript-language-server/typescript-language-server#workspacedidchangeconfiguration

[Drag13]

Still a valid point. Any progress here?

[me4502]

Some of these diagnostics appear to impair functionality of VSCode (and presumably other IDEs using ts server) when not using specific libraries. For example, diagnostic 2593,

(Cannot find name 'describe'. Do you need to install type definitions for a test runner? Try npm i --save-dev @types/jest or npm i --save-dev @types/mocha and then add 'jest' or 'mocha' to the types field in your tsconfig.)

disables the normal VSCode import suggestions and removes both describe and it from the "Add all missing imports" action.

This diagnostic code is making the assumption that global types are being injected by a test framework, which is not the case by default on Vitest, and is not actually available when running Jest under ESM or when using the inbuilt Node test runner. This means IDE import actions are partially broken for these cases due to this diagnostic.

[derammo]

I'm don't know enough about the code base to take this through the process of adding a compiler option, which presumably touches protocols, command line, etc. There would also need to be tests to submit it, but the code to actually make this work is extremely short. Here is an implementation:

https://github.com/microsoft/TypeScript/compare/main...derammo:TypeScript:derammo_suppressDiagnostics?expand=1

[patrickReiis]

Any status? How can I get rid of 80005: 'require' call may be converted to an import.?

[rootgrandfather]

any progress? god?

[YehudaKremer]

For TypeScript diagnostic errors you can use Disable TS Errors extension.

Works well for me, for example (settings.json):

{
  "editor.formatOnSave": true,
  "disableTsErrors.customizations": [
    {
      "code": [
        2304,
        2322,
        2339
      ],
      "severity": "off"
    }
  ]
}