no- prefix in eslint is used for rules whichdisallow /disable some functionality.

Changing names of rules is considered breaking change and can be done only in major release

I don't disagree that some of rules should not be prefixed withno-, if options allow to inverse (enforce) functionality.

https://eslint.org/docs/rules/

Changing names of rules is considered breaking change

How about rule aliases? As in, having ano-parameter-properties file that just re-exportsparameter-properties? At the next major version it could log a deprecation warning, and a major version after that, log an error, and one major version later, stop existing.

Just to clarify: for rules that aren't yet ported, would removing theno- be acceptable?

eslint provides api for deprecation and replacing rules

• deprecated (boolean) indicates whether the rule has been deprecated. You may omit the deprecated property if the rule has not been deprecated.
• replacedBy (array) in the case of a deprecated rule, specifies replacement rule(s)

https://eslint.org/docs/developer-guide/working-with-rules#rule-basics

I don't have "final" answer for you now about usage of prefix.

my opinion is that we should follow eslint rule naming convention

https://eslint.org/docs/developer-guide/working-with-rules#rule-naming-conventions

The rule naming conventions for ESLint are fairly simple:

• If your rule is disallowing something, prefix it with no- such as no-eval for disallowing eval() and no-debugger for disallowing debugger.
• If your rule is enforcing the inclusion of something, use a short name without a special prefix.
• Use dashes between words.

@typescript-eslint/core-team what is your opinion on this?

Yeah we need to knuckle out some guidance around this. Most of ourno- rules were built because someone had an opinion about a ts feature and nobody had an opinion about ever wanting that feature on!

Now that we are much bigger, we should definitely nut out some guidance docs around this.no- rules only work in rare cases where it's bad to use a feature, or it makes no sense to have an inverse check (as in no-eval or no-explicit-any).

We can deprecate and redirect users to new rules to replace some of theno- rules without doing a major bump, but removing them obviously is breaking.

Note also that you can'tjust rename the rule fromno- to "nono-". You also have to flip what"always" /"never" / et al mean.

Not saying it wouldn't be a good change, it's just not simple to do, and can't really be done with aliases unless there is some refactoring done.

Just I mention about the deprecation policy in ESLint core.

• Deprecating a rule happens in a minor version.
• Deprecated rules are frozen. People can continue to use the deprecated rules, but they don't change the deprecated rules even if bugs exist.
• They make renaming a rule in a minor version if it's needed because renaming is a combination of deprecating a rule and adding a new rule. (it'snot alias.)
• Some precedents exist in core. For example,no-comma-dangle had been renamed tocomma-dangle because it's a rule that enforces the style about trailing commas rather than that disallows trailing commas.

Related references:

• https://github.com/eslint/eslint#semantic-versioning-policy
• https://eslint.org/docs/user-guide/rule-deprecation

Should we do a 2.0 and get rid of all theno- rules? Since we don’t have the support guarantees of ESLint core, we should be OK to just remove them.

A number of theno- rules make sense as things that won't be turned on and have no inverse, so a blanket rule againstno- prefixes is a bad idea.
I agree though that it makes sense for us to advise against that naming if it's feasible that we will add inverse functionality to a rule.

Going through the list (checkmark = imo should be renamed):

• no-angle-bracket-type-assertion
  • IMO shouldn't have an inverse because the<cast>value syntax is essentially deprecated.
• no-array-constructor
  • has no inverse
  • maybe should be renamed though because it sounds like you shouldn't use any array constructors, when it's only enforcing correct usage.
• no-empty-interface
  • has no inverse
• no-explicit-any
  • has no inverse
• no-extraneous-class
  • I doubt anyone would ever want the inverse of this unless they absolutely love java.
  • would be good to rename this so it's clearer though (no-class-as-namespace?)
• no-inferrable-types
  • could feasibly have an inverse but I don't think it makes sense to have one
• no-misused-new
  • has no inverse
• no-namespace
  • would people want an inverse for this? I haven't ever seen namespace used outside of definition files.
• no-non-null-assertion
  • could have an inverse? (would require typechecking though)
• no-object-literal-type-assertion
  • inverse seems weird here due to the type-unsoundness whichas X introduces?
• no-parameter-properties
  • needs inverse
• no-this-alias
  • has no inverse
• no-triple-slash-reference
  • has no inverse (because/// <ref /> is essentially deprecated)
• no-type-alias
  • needs inverse
• no-unnecessary-type-assertion
  • has no inverse
• no-unused-vars
  • has no inverse
• no-use-before-define
  • has no inverse
• no-useless-constructor
  • has no inverse (well technically it does - force every class to have at least a useless constructor, but that seems like a really poor practice).
• no-var-requires
  • has no inverse that makes sense in TS.

i don't see point in rules like:

• no-non-null-assertion: inverted -> what it will check? that you need null assertion?
• no-type-alias: inverted -> there should no be inverse, we should have 2nd rule:prefer-type-alias/no-simple-interfaces or something like that

it's better to keep rules simple

the problem with two rules is now you can have a state where you're both not allowed to use interfaces and not allowed to use type aliases.

we can have a ruletype-definition-style which has an option to pick eitherinterface ortype-alias. It's still simple and prevents invalid states.

Regarding the change to add options toexplicit-member-visibility in#214 I guess the better name for the rule would bemember-visibility I assume that this would however be a breaking change.
What's the process/plan for implementing these changes as a whole?

Marking as accepting breaking change PRs per the list in#203 (comment).

would like to add that some "no-" rules' names don't lend themselves well to understanding; for example, "no-inferrable-types" can (and has multiple times on my team) give the impression that it does the opposite of what it does. It has been floated that "force-type-inference" would be a good disambiguation.

Can we at least keep theno- prefix for extension rules? I don't think the benefits of simplifying the APIs apply to rules that are already in ESLint, and this makes migrating from ESLint rules more confusing.

For theno- rules that might want to be renamed, filed:

• Rule rename: no-array-constructor -> array-constructor #6034
• Rule rename: no-extraneous-class -> no-class-as-namespace #6035

Forno-type-alias,https://typescript-eslint.io/rules/consistent-type-definitions exists now. I filed#6036 to consider deprecatingno-type-alias.