I'd like a way to run all my eslint through betterer

[innermatrix]

Right now in betterer (5.x) the only way to run eslint is

• Have one set of rules in eslint config files that apply only when running eslint outside of betterer
• Have a second set of rules in betterer config files that apply only when running eslint inside betterer

because the current implementation of @beterrer/eslint replaces the ruleset from eslint with a ruleset consisting only of betterer eslint rules (and turns off all other rules in the eslint config).

The problem with this is that

• in order to run all my rules (both the ones that I am adopting incrementally and the ones that I have fully adopted), I have to run both eslint and betterer
• in a TS project using @typescript-eslint rules that rely on type information, eslint has high startup cost (about 20s in my project) because it rebuild all the type information on any invocation — even if running eslint on a single file (for example, in pre-commit mode, it still takes 20s to rebuild all the typing information)… this is a known issue with eslint/TypeScript, and as far as I am aware there is some work in eslint to address it, but it's nowhere near ready
• so if I run eslint in pre-commit I end up with a 20s delay (which is already painful) but if I run both eslint and betterer, I end up with a 40s delay (which my team will not put up with). I could potentially consider running eslint and betterer in parallel, but that has other issues (mainly with memory utilization, which then leads to its own set of performance problems).

What I would really like to do here is just… let all my existing eslint rules pass through betterer, and then have some additional rules in betterer config that I am adopting incrementally. This works fine, I think, because for rules that I have already fully adopted, I am going to have zero errors, so a betterer rule with a smaller constraint will keep them at zero, which is what I want.

So, what I would like is an option to @betterer/eslint that lets me say "run all existing rules plus the ones I passed you in" rather than "disable all existing rules and only use the ones I passed you in".

I'd be willing to contribute a PR for this if you think it's a useful idea.

[phenomnomnominal]

So it's not really a hard rule, but philsophically I think it's best if the core published @betterer/* packages strictly do just the incremental parts. That said, it should be quite straightforward for you to _wrap* the eslint implementation to read your whole config file and pass that as the set of override rules. Does that sound like a reasonable option to you?

[innermatrix]

I hate it when a sensible philosophy runs into senseless reality. 🙂

I can get what I want just by patch-packageing, so I don’t have to fork @betterer/eslint. Carry on and ty!

[innermatrix]

Actually I have a different approach here; I'm going to

1. mark the eslint rules that I am in the middle of incrementally adopting to emit warnings instead of errors in the eslint config
2. output JSON results from eslint
3. write a betterer plugin that, instead of running eslint, ingests the eslint JSON output, extracts all warnings, and runs them through a betterer constraint.

That way I can keep all my eslint config in one place (and specifically don't have to duplicate my filename globs between eslint and betterer), get the incremental adoption behavior of betterer that I am after, and as a bonus will get IDE hints about the eslint warnings.

Lmk if you have any interest in adopting the eslint JSON betterer plugin into the main betterer repo, in which case I'm happy to send a PR.