Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Make error TS2367 optional

See original GitHub issue


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

✅ 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:open
  • Created a year ago
  • Reactions:1
  • Comments:7 (4 by maintainers)

github_iconTop GitHub Comments

MartinJohnscommented, Aug 4, 2022
RyanCavanaughcommented, Aug 4, 2022

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") {
  } else {

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Typescript error This condition will always return 'true' since ...
If one of these conditions is true, I will send an error message. The error I am receiving is: [ts] This condition will...
Read more >
TypeScript errors and how to fix them
The easiest way to fix the error is to make age optional as well: ... error TS2367: This condition will always return 'false'...
Read more >
3xs7puhhf - TypeScript - OneCompiler
Output: script.ts(8,11): error TS2367: This condition will always return 'false' since the types 'number' and 'string' have no overlap. script.ts ...
Read more >
Avoid Catching Errors with TypeScript 2.5 Optional Catch ...
... making catch clauses optional. Most of the time, you'll find yourself writing a try/catch but not really caring about the thrown error....
Read more >
element implicitly has an 'any' type because expression of ...
main.ts:21:9 - error TS2367: This condition will always return 'false' since the ... make IAction.value a non-optional string; make all the properties of ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found