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

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/ban-types/

Description

https://typescript-eslint.io/play/#ts=5.4.2&fileType=.ts&code=C4TwDgpgBANg9gdwgJwPICMBWUC8UDeAUFFAPSlQAWcA5hIQL4DchhoksiKGmATLgWaEgA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6AIwEMnajTUMkRNGgB7aJHBgAviGlA&tsconfig=&tokens=false

I believe this behavior might be unintended, as the presence of comments should ideally not affect the linting rules for identifying empty object types. It would be beneficial for code quality and consistency if the ban-types rule could be enhanced to trigger an error regardless of the presence of comments within the type object.

I propose an enhancement to the ban-types rule to ensure it consistently identifies and flags empty object types, even when comments are present inside the type declaration. This change would help developers maintain higher code standards and avoid potential issues related to the use of empty object types in TypeScript.

Thank you for considering this enhancement to the ban-types rule. I believe it will make a valuable contribution to the robustness and consistency of TypeScript linting with ESLint.

Fail

type lowerObj = {
  // Expecting a lint error"
};

Pass

type lowerObj2 = {};

Additional Info

No response