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. 😄

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¹ 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¹; already planning to move it to an optional peer. 😅
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.
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 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. 😬

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

Footnotes

1. Not counting novel transitives. ↩ ↩²