Update configs format to support defineConfig()

[nzakas]

The format for flat configs in eslint-plugin-jsx-a11y is outside the norm for ESLint plugins.

Currently:

const jsxA11y= require('eslint-plugin-jsx-a11y');

module.exports = [
    jsxA11y.flatConfigs.recommended
];

What I'd like to see:

import jsxA11y from "eslint-plugin-jsx-a11y";
import { defineConfig } from "eslint";

export default defineConfig({
    files: ["**/*.jsx"],
    plugins: {
        "jsx-a11y": jsxA11y
    },
    extends: ["jsx-a11y/recommended"]
});

You can support this newer format by renaming flatConfigs.recommended to configs["flat/recommended"] (or by exporting the same config with both names). See the docs here:
https://eslint.org/docs/latest/extend/plugins#backwards-compatibility-for-legacy-configs

[ljharb]

I really don't want a property that's not an identifier.

[nzakas]

You can name it whatever you want, but jsx-a11y/recommended is an eslintrc-style config, then you can define jsx-a11y/flat/recommended so that defineConfig() can use jsx-a11y/recommended.

Otherwise, you can create a different name like jsx-a11y/modernRecommended.

The bottom line is that the current approach is not in line with the ecosystem and it's confusing to users. I'm working with a client right now where this came up. So any config name that can be used in defineConfig() would be a big improvement.

[ljharb]

That's because the ecosystem opted not to enforce a specific format. The confusion is the expectation that anything eslint doesn't force, is always going to be the case.

[nzakas]

While I'd be happy to wax philosophical on this point, it won't change my request. The best thing for users is to have plugins adhere to the recommended way of publishing configs in plugins. Given the popularity of this plugin, it would benefit the entire ecosystem for it to follow suit.

[ljharb]

The best thing for users is requiring things instead of recommending them :-)

Are you planning on making that convention enforced in eslint 10? If so, that would be a pretty compelling argument for cleaving to it now.

[nzakas]

I'm having a hard time understanding your resistance to this small change that would make life easier for ESLint users, including those who use your plugin, regardless of whether ESLint can enforce this or not. It's technically very difficult to enforce conventions with the new config system because users are the ones importing the plugins, so all we can do is document the approach, which we have:

https://eslint.org/docs/latest/extend/plugins#configs-in-plugins
https://eslint.org/docs/latest/extend/plugins#backwards-compatibility-for-legacy-configs

I know you enjoy a good debate, but this is not a debate. I'm asking please, both as a steward of the ESLint project and as a sponsor of this plugin to help make the user experience for your plugin better.

[pascalmtts]

I also would love to see this. I stumbled over this when trying to use defineConfig in our eslint config, but currently that is not possible with your plugin.