Thanks for the PR,@G-Rath!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitorsper day.

I'm interested in hearing what you've found better overall: lots of small nice rules, or a couple of big (but ideally still relatively straightforward in layout) rules

I don't think there's a hard-and-fast rule.
The thing I've learned from doing this is it depends on the use case.

Having one rule makes it easy to for a user to turn on everything at once, lets you deduplicate code, etc, but it comes with the drawback of only allowing a single level for the options - it's all an error, or it's all a warning.

Having two rules makes it harder for the user, as they have to review more docs, and it means you have to work harder to deduplicate code, etc, but it means that users can independently configure the level of each.

It entirely depends on the use case. If you think people will want individual levels, then two rules make sense. If you think people will not care, then one rule makes sense.

Examples:

For naming conventions, there iscamelcase,class-name-casing,generic-type-naming,member-naming, etc. All of these rules are a pain to configure separately because they all have different options, and nobody will ever want different levels for the different naming sections, so it makes complete sense to merge them all into a single naming rule (#1318).

In the case of type assertions, in2.0.0, I merged a number of rules into one rule (consistent-type-assertions). However this ran into the problem that people want to be able to both enforce that nobody uses angle bracket assertions, and nobody uses object type assertions. Because it's all one rule, someone mighteslint-disable the single rule, which then means they are free to accidentally use an angle bracket assertion.
In that case, it was a mistake - there should be two separate rules.

Inthis example - it could go either way, it could be valid that someone might want error level forban-ts-nocheck, as it has huge impact in disabling the entire file, but a warning forban-ts-ignore, as it only disables a single line.

But I highly doubt anyone would want that.
I think this would make a lot sense together as a single rule likeban-ts-directive, with options for each of them (@ts-nocheck default true,@ts-ignore default true,@ts-check default false).

I don't think there's a hard-and-fast rule.
The thing I've learned from doing this is it depends on the use case.

Thanks for taking the time write up such a detailed response - it's pretty much the same as what I've been thinking in my head, but it's useful to hear independently aligns with a repo of this scale.

Could you please merge this and ban-ts-ignore together, and deprecate ban-ts-ignore?

Sure thing - I'll do that when I get home in a few hours :) (or tomorrow)

I think I prefer the simpler "comment" over "directive", just for ease of spelling & less technical.

I might have slightly forgotten about this 😬

I'll try and get it done over this weekend, so that it's ready in time for#1423