Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Base rule extension: [no-constant-binary-condition] Remove the parts of the rule that TypeScript also reports on #9973

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
JoshuaKGoldberg opened this issue Sep 12, 2024 · 8 comments
Assignees
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: new base rule extension New base rule extension required to handle a TS specific case locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@JoshuaKGoldberg
Copy link
Member

Before You File a Proposal Please Confirm You Have Done The Following...

My proposal is suitable for this project

  • My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the base rule

https://eslint.org/docs/latest/rules/no-constant-binary-expression

Description

Coming over from https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#disallowed-nullish-and-truthy-checks1 -> #9653: TypeScript now includes a "Disallowed Nullish and Truthy Checks" feature. The blog post says:

Similar results can be achieved by enabling the ESLint no-constant-binary-expression rule, and you can see some of the results they achieved in their blog post; but the new checks TypeScript performs does not have perfect overlap with the ESLint rule, and we also believe there is a lot of value in having these checks built into TypeScript itself.

Shall we write an extension rule that only reports on what TypeScript doesn't?

Fail

if (true || inDebuggingOrDevelopmentEnvironment()) {
    // ...
}

Pass

if (true && inDebuggingOrDevelopmentEnvironment()) {
    // ...
}

Additional Info

💖

@JoshuaKGoldberg JoshuaKGoldberg added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look enhancement: new base rule extension New base rule extension required to handle a TS specific case labels Sep 12, 2024
@kirkwaiblinger
Copy link
Member

My immediate question when I read those release notes, and my question for this issue, is - how does no-unnecessary-condition play into this? That currently flags both the pass and fail examples 🤔

@JoshuaKGoldberg
Copy link
Member Author

That is a great question. Are there any cases that no-unnecessary-condition won't catch but no-constant-binary-condition would?

@kirkwaiblinger
Copy link
Member

Idk, that's my question 🤷‍♂️😂

@kirkwaiblinger
Copy link
Member

Also, is the TS design pure syntactic analysis, or does it take into account types? 🤷‍♂️

@JoshuaKGoldberg
Copy link
Member Author

I poked around a bit. It's >=99% covered by no-unnecessary-condition. Anything not currently covered by no-unnecessary-condition, we should consider a separate bug report or feature request for that rule.

For now, we can just turn off no-constant-binary-condition in our core ESLint configs (eslint-recommended).

@JoshuaKGoldberg JoshuaKGoldberg added accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for team members to take a look labels Sep 13, 2024
@JoshuaKGoldberg JoshuaKGoldberg self-assigned this Sep 13, 2024
@rubiesonthesky
Copy link
Contributor

Is there rush to do remove it from recommended set? I mean, it’s not big issue if it’s removed from recommended set as used can add it back. But I think many will not read changelog to notice this. Typescript 5.6 just released so I there are probably bunch of projects that have not updated yet or can’t update for few months.

no-unnecessary-condition is nice but it needs strict null checks if I understood correctly?

Maybe what I would suggest is to merge the change when Typescript 5.7 is released? (Or about there, just give a little bit more time for people to benefit this rule if they are not using 5.6 yet) :)

I know that Angular users are small minority but as far as I understood, only Angular 19 will support Typescript 5.6 and its release is scheduled to “Week of 2024-11-19”

@bradzacher
Copy link
Member

I would tend to agree - I don't think there's any great rush. From experience the errors that these checks reveal are very much few and far between. They're real bugs but they don't occur often enough for us to rush out a disable to deduplicate the errors. And anyways - double reporting on these things ain't bad cos they are real, provable bugs in the code.

@JoshuaKGoldberg
Copy link
Member Author

👍 closing for now. We can revisit in a year or two once TS<5.5 is much less common.

@JoshuaKGoldberg JoshuaKGoldberg closed this as not planned Won't fix, can't repro, duplicate, stale Oct 10, 2024
@github-actions github-actions bot added the locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. label Oct 18, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: new base rule extension New base rule extension required to handle a TS specific case locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
4 participants