Make error TS2367 optional
See original GitHub issueSuggestion
When developing, you sometimes produce unfinished code, that you want to compile. In these cases, certain errors are hindering compilation unnecessarily. E.g. error TS2367 “This condition will always return ‘false’ since the types ‘“abc”’ and ‘“def”’ have no overlap.”
While I certainly want that error to throw in a CI run, I don’t want it to block my dev flow.
🔍 Search Terms
TS2367 disable error globaly https://github.com/Microsoft/TypeScript/issues/29950
✅ Viability Checklist
My suggestion meets these guidelines:
- 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 feature would agree with the rest of TypeScript’s Design Goals.
⭐ Suggestion
Either a way to disable errors like you can e.g. with eslint,
or more specifically to this issue, a compiler flag to disable TS2367.
📃 Motivating Example
Concider this (react) example
const PaymentWallet = (props: { walletType: "googlepay" }) => {
switch (props.walletType) {
case "googlepay":
return <GooglepayComponent/>;
case "applepay":
return <ApplepayComponent/>;
}
}
Let’s assume, the switch case is a bit more complex and maybe I copied it from somewhere else. It is clear, that the applepay case will never be called according to the functions type signature. I want that error when building for deploy as it catches an obvious error.
But right now I am just developing happily. I don’t want to remove code, that I will later need anyways. I just want to ignore the warning without adding something like /* @ts-ignore */ (as I might forget to remove it later).
Instead, I want a separate tsconfig for dev, which is much more relaxed and shows me a warning instead of an error and still lets me compile. Why nicer to work with.
💻 Use Cases
This is mainly a feature for improving development. Current workaround would be, to make sure that all you intermediate code does not produce warnings. That is tedious as often times in dev you don’t know for sure which code will make it into prod. Why cleaning all that code, if we might throw it away later?
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:7 (4 by maintainers)
Top GitHub Comments
@fatcerberus FYI #13280
Things have been going pretty OK without a true warning/error distinction so far and opening up the pandora’s box of “well this is an error and this is a warning and this is a warning under these conditions otherwise an error and these are the six thousand tsc flags you can use to toggle this” is just not something that seems worthwhile.
Even in this specific instance it’s hard to reason about whether this is an “error” or a “warning”. If you wrote something like
Well now your code is extremely wrong in a way that’s probably very dangerous. But there’s nothing in principle different about this case and the one in the OP.
Our longstanding philosophy is that dev toolchains should not block execution on typecheck.