Make error TS2367 optional

Suggestion

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?

[MartinJohns]

@fatcerberus FYI #13280

[RyanCavanaugh]

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

function formatHardDrive(mode: "test" | "actually-do-it") {
  if (mode === "tst") {
    mockFormatHardDrive();
  } else {
    actuallyFormatHardDrive();
  }
}

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.