Repo: improved management of extension rules

[bradzacher]

Suggestion

Forks

Cons:

• They require us to manually watch the base rule implementation so that we can upstream the changes into our fork to maintain parity.

Pros:

• The user gets a consistent experience with the rule regardless of the underlying ESLint version they use
• They don't require us to maintain backwards-compatability hacks to ensure that we support older ESLint versions

Overrides

Cons:

• Implementation can be somewhat convoluted as we hack around and abuse existing selectors in the base rule
• We have to maintain support for older ESLint versions
• We have to pay attention to the base rule implementation in case it changes substantially (eg different selectors, reworked internal logic).

Pros:

• There's less code for us to maintain overall - which is pretty big for some of the formatting extension rules

---

Originally we tried to do an override wherever possible to save maintenance burden. However we've found over time that we're tightly relying on ESLint's implementations - which can be pretty brittle and can require some hacks to maintain. Some rules required forking because our changes needed access to internal rule logic.

This means that currently our extension rules are a mixed bag - some of them are complete forks, others are slightly hacky overrides. As shown above; neither option is fantastic, but having both also is an even worse state to be in I think.

I propose that we standardise our approach on full forks. Whilst there is more code in our repo - it does mean that we can better manage our code and do fewer hacks.

This ofc does bring in the problem of us needing to watch ESLint releases very closely - however I think we can probably automate this with an action that does the following:

1. checkout the ESLint repo's latest release tag.
2. get all the changed files since the previous release.
3. if any of the changed files are files we are watching, then file an issue to alert us of the changes that we need to merge in.

There'd still be the manual effort of actioning this issue - but at least we won't miss anything like we have in the past (eg #4910)