Add True Flat Configs

[Kenneth-Sills]

The resolution of #2 was adding documentation on how to use this project in a flat configuration setup using the eslintrc library, but we still need to migrate to a true flat configuration format going forward.

I'd like to take this opportunity to include different configs for projects using Stylistic or not, as well as a recommended configuration that includes QoL / best practices that may deviate from a 1:1 compliance with upstream (as initially mentioned here).

See ESLint documentation on writing plugins here. An arbitrary example project can be seen here.

[Kenneth-Sills]

Another rule change that could go into recommended: ignoreOverrideMethods for class-methods-use-this, as mentioned here.

[claabs]

Sorry about using issues for this, but I couldn't find a way to reach out.

Glad to see you're forking this project; I saw your name all over the place on the old one. The past couple days I was working on my unpublished fork which takes a more breaking approach. Notably:

• Only flat config is supported
• Replaces eslint-plugin-import with eslint-plugin-import-x to support ESLint 9

It dynamically replaces the rule keys for import/ to import-x/, and converts airbnb's deprecated formatting rules to @stylistic/. However, the prettier overrides for stylistic rules are currently a roadblock for regular use.

Let me know if I should try to integrating my changes as a PR, or if you feel it's too destructive.

[Kenneth-Sills]

No worries at all, using issues / discussions is perfect! This way other people can see them as well and chime in with thoughts/opinions. :smile:

There's no problem with breaking changes, but I would like to continue offering a legacy style config, at least until ESLint 9 is officially supported by the upstream Airbnb project. Gives end-users more time to get settled, since I know from experience how frustrating the whole experience has been migrating from both CJS to ESM and legacy to flat configs.

The eslint-plugin-import situation stinks, which I won't go into again. But I'm inclined to agree we should replace it with eslint-plugin-import-x. To play devil's advocate, I can see a few arguments against (see below), so I'll probably stew on this a couple of days before making a decision.

Click to Open

1. The import plugin is pretty chunky at 2M[^1] and `overrides` isn't transitive, so this would mean all of our users would have to download both copies. I was already pretty loathe to add `@stylistic`, which is also a cool 2M[^1]; already planning to move it to an optional peer. :sweat_smile: 2. As controversial as they can be, the maintainer for the mainline project has solid track record of quality assurance and stays pretty consistently active. I mean, one of the "issues" is that they won't drop support going back as far as Node 0.4! The new project may not have quite the same longevity or stability. [For example](https://github.com/un-ts/eslint-plugin-import-x/issues/113). 3. This solves a pretty minor problem. Javascript projects shouldn't be using a Typescript configuration, so this mainly affects linting configurations, and that's not necessarily worth overhead when they can just throw in an `ignore` on the rule. And it's not really *our* problem to solve, more Airbnb's upstream. Furthermore, there's an argument a user should use Typescript [project references](https://www.typescriptlang.org/docs/handbook/project-references.html) with `allowJs` and `checkJs` to also lint their configs, in which case they'd already be covered.

Out of respect for your time, I'd say it's worth waiting a couple of weeks before working on a PR. I've gotten myself a bit booked at work, and the OSS time I have I'd like to spend finalizing the project migration and cleaning things up a bit (validation, testing, Typescript). I wouldn't want to not have time to review, then end up causing conflicts for you to resolve. :grimacing:

Thank you for your time and offer to help, though, it's much appreciated!

[^1]: Not counting novel transitives.