Allow all error messages from tsc compiler to have their severity customized

[alandsidel]

🔍 Search Terms

compiler custom error severity

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Some errors can be enabled or disabled via setting certain flags to true or false in the tsconfig.json file. It would be nice if these errors could have their severity set as well.

📃 Motivating Example

During development and testing it is common to comment out a block of code and then compile and run it again.
In certain circumstances this causes novel errors to appear, for example if you comment out all uses of a variable or function argument, you must additionally remove the declaration of the variable or prefix the argument with an underscore to avoid errors such as TS6133. As such notices can be disabled and leave functioning code, via knobs like noUnusedLocals and noUnusedParameters, they are not truly errors.

There should be a compiler-wide option to emit such "errors" as warnings, so testing can proceed without further code modifications, as such modifications are prone to being accidentally left behind, as are such compiler configuration flags.

💻 Use Cases

1. What do you want to use this for?
   Testing and debugging of code.

2. What shortcomings exist with current approaches?
   You can only turn these errors on, preventing compilation entirely, or off, which causes them to be ignored completely. This forces you to decide between making further code modifications to do testing, which may introduce errors, or to disable the compiler options, which may cause the unwanted code smell to be left. A warning would allow the code to run but continually draw the developers eye until it is addressed, which is the historic purpose of having warnings as a step between clean compiler output and show-stopping error output.

3. What workarounds are you using in the meantime?
   There are no workarounds. I am disabling compiler options such as noUnusedLocals and noUnusedParameters in some cases, prefixing arguments with underscores in others, and then undoing those changes after the debugging is complete -- only to have to do it all again the next time.

[MartinJohns]

Duplicate of #13408.

You can only turn these errors on, preventing compilation entirely, or off, which causes them to be ignored completely. This forces you to decide between making further code modifications to do testing, which may introduce errors, or to disable the compiler options, which may cause the unwanted code smell to be left.

Imo that's what noEmitOnError set to false is there for. The checks still happen, but your code is compiled as well.

[alandsidel]

Imo that's what noEmitOnError set to false is there for. The checks still happen, but your code is compiled as well.

I wasn't even aware of this option, thanks for the pointer. It turns out that it defaults to false anyway, so the code is being compiled even with the errors being printed. The exit code of tsc being non-zero lead me to believe it was aborting compilation.

I'd still rather these kinds of non-fatal issues were emitted as warnings and not errors for the reason outlined, but I can work with this.