Skip to content
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

📎 Implement lint/noEmptyBlockStatements - eslint/no-empty eslint/no-empty-static-block #39

Closed
Conaclos opened this issue Aug 23, 2023 · 5 comments · Fixed by #521
Closed
Labels
A-Linter Area: linter good first issue Good for newcomers L-JavaScript Language: JavaScript and super languages

Comments

@Conaclos
Copy link
Member

Conaclos commented Aug 23, 2023

Description

This lint rule should integrate both no-empty and no-empty-static-block rules.

Want to contribute? Lets you know you are interested! We will assign you to the issue to prevent several people to work on the same issue. Don't worry, we can unassign you later if you are no longer interested in the issue! Read our contributing guide and analyzer contributing guide.

@Conaclos Conaclos changed the title 📎 lint/noEmptyBlockStatements 📎 lint/noEmptyBlockStatements Aug 23, 2023
@Conaclos Conaclos changed the title 📎 lint/noEmptyBlockStatements 📎 Implement lint/noEmptyBlockStatements Aug 23, 2023
@Conaclos Conaclos changed the title 📎 Implement lint/noEmptyBlockStatements 📎 Implement lint/noEmptyBlockStatements - eslint/no-empty eslint/no-empty-static-block Aug 23, 2023
@Conaclos Conaclos added A-Linter Area: linter L-JavaScript Language: JavaScript and super languages good first issue Good for newcomers labels Aug 23, 2023
@ematipico
Copy link
Member

What's the difference between this rule and #42? It's worth an explanation in the description

@Conaclos
Copy link
Member Author

Conaclos commented Aug 28, 2023

What's the difference between this rule and #42? It's worth an explanation in the description

In contrast to #42, the rule prohibits any empty block statements.
Examples of incorrect code:

if (cond) {}

while (cond) {}

function f() {}

However, the following example also triggers #42:

{}

@ematipico
Copy link
Member

So we would have two rules that trigger the same code? That doesn't seem right to me.

I wonder if at this point if we should have only one rule that handles all the block statements. Or at least make sure that they don't conflict each other.

@Conaclos
Copy link
Member Author

I wonder if at this point if we should have only one rule that handles all the block statements

I think you are right. We could thus regroup these two rule under the noUselessBlockStatements name.

@andrewangelle
Copy link
Contributor

Hello! If a fix for this issue is still needed, I'd like to give it a shot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Linter Area: linter good first issue Good for newcomers L-JavaScript Language: JavaScript and super languages
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants