Add support for diagnostic severities

[egamma]

TypeScript has added compiler options for lint level checks like noUnusedParameters or noUnusedLocals in tsconfig.json (which is goodness). Today when such an option is enabled then the corresponding issues are reported by TypeScript in the same way as semantic or syntax errors. There is no notion of severity.

Background

We are using tslint to develop VS Code and we have used tslint rules to detect unused locals. TSLint rule failures are reported in VS code as warnings and we had the setup that lint style issue are shown as warnings and the typescript issues (syntax, semantic) are shown as errors. Now that typescript added more lint style checks we no longer get the distinction when developing between lint level warnings and semantic errors. The situation has become worse with tslint 4.0, there tslint has started to deprecate rules which are covered by TypeScript compiler options. This makes good sense, but it means we are now starting to see 'unused locals' reported as errors and no longer as warnings as we did before.

Suggestion

Support that the user can define in the tsconfig.json whether a check enabled by compiler option should be reported as error or warning.

eslint supports to configure the severity of an option. Here is an example the eslint documentation:

{
    "rules": {
        "eqeqeq": "off",
        "curly": "warn",
        "quotes": ["error", "double"]
    }
}

// CC @waderyan @mjbvz

[kkovalevskiy]

Also it'd be nice to have ability to disable some checks for certain places in the code by corresponding comments as it's already implemented in tslint - /* tslint:disable */, etc (https://palantir.github.io/tslint/usage/rule-flags/)

[n9niwas]

+1 would be nice to have that.

[mhegazy]

also discussed in #6802

[donaldpipowitch]

I'd love to see this feature in the roadmap. Could this become part of 2.3?

I personally need this for warnings for

• noImplicitAny
• noUnusedLocals
• noUnusedParameters

[mhegazy]

Also referenced as the underlying issue in #15550

[jez9999]

This feature seems to be going very slowly - nearly a year and still only in the suggestion phase?

Personally I would love to see this feature. "Unreachable code detected" should absolutely be a warning, not an error. During development I regularly return before some code I temporarily want to ignore, and it is by design. It is not an error.

[jez9999]

Just in case anyone was having the annoyance with the "unreachable code" error I was, this error can be completely disabled with "allowUnreachableCode": true in your tsconfig.json.