Update configs format for use with defineConfig()

[nzakas]

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

Currently:

const react = require('eslint-plugin-react');

module.exports = [
    react.configs.flat.recommended
];

What I'd like to see:

import react from "eslint-plugin-react";
import { defineConfig } from "eslint";

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

You can support this newer format by renaming flat.recommended to 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]

If eslint doesn't force it, then I'm not sure how important that norm is.

[nzakas]

The fact that I opened this issue should tell you that it's important. :) This problem of having different plugins specifying different ways to include configs is what motivated the creation of defineConfig() in the first place.

I'm working with a client right now where this came up. The expectation is that plugins support the name/config-name format for extends, and people are trying that first and then becoming confused when it doesn't work. Only then do they go and read the README, and then are still left confused as to why this plugin is different.

[ljharb]

Why is that the expectation tho? neither eslint 8 or 9 mandates a format, so there should be no expectation of a single format, and imo defineConfig shouldn't be a subset of what eslint mandates.

Having property names that aren't identifiers is "icky" and inconvenient.

[ljharb]

If your goal is to specify a protocol, then i think a more appropriate direction would be a symbol, exported by eslint itself, that eslint always looks for on objects it's given, that links to the config - then users wouldn't have to type anything to get there.

[JamesJosephFinn]

defineConfig() helper is adding red squigglies to this config in VS Code, because of this issue, I believe.

You can't add react.configs.flat.recommended top-level inside defineConfig().

Trying to spread it (i.e. ...react.configs.flat.recommended) doesn't work, either.

Neither does putting it, spreaded or un-spreaded, as an extends in its own config object:

export default defineConfig(
    // other config object ...
    {
        files: ["**/*.jsx"],
        extends: [react.configs.flat.recommended]
        // or extends: [...react.configs.flat.recommended]
    }
    // another config object ...
);

Config fun.

[JamesJosephFinn]

defineConfig() helper accepts the following as valid in VSCode. (But it will, presumably, have unintended side-effects?)

export default defineConfig([
    {
        ...react.configs.flat.recommended,
        files: ["**/*.{jsx,tsx}"],
    },
])

Side note: this same syntax is rejected in the IDE by defineConfig() for the companion config eslint-plugin-jsx-a11y (corresponding issue: jsx-eslint/eslint-plugin-jsx-a11y#1061).

[nzakas]

@ljharb while I appreciate your feedback, this is coming way too late in the process. We created defineConfig() in this way specifically because so many plugins were already using "flat/*" for the names of their configs. (see the RFC: eslint/rfcs#126).

[ljharb]

I don't see anything in that RFC that indicates that eslint will be cargoculting an unenforceable convention into the tool, though. Where was that discussed?

[RobinSteil]

For anyone wondering

This works for me

// eslint.config.ts
export default defineConfig(
 ...
  reactPlugin.configs.flat.recommended!,
  reactPlugin.configs.flat["jsx-runtime"]!,
 ...
);

Note that because the type of the flat object is Record<string, reactPlugin.ReactFlatConfig> acessing its properties returns an object of type reactPlugin.ReactFlatConfig | undefined, hence the non-null assertion.

[Leland]

As someone newly setting up ESLint with this plugin, I will cop to this repo's README being confusing

The first section is for legacy - alright, skipping - and then you get to "new: eslint.config.js"... but the plugin code samples are still using the old format!

It's worth noting that ESLint's extremely terse starter configuration is:

import { defineConfig } from "eslint/config";
import globals from "globals";
import js from "@eslint/js";

export default defineConfig([
	{ files: ["**/*.js"], languageOptions: { globals: globals.browser } },
	{ files: ["**/*.js"], plugins: { js }, extends: ["js/recommended"] },
]);

FWIW, here's the final setup I landed on https://gist.github.com/Leland/043d73224fb957b1aac24cf275ff0535

[JamesJosephFinn]

@Leland After banging my head against keyboard to no avail, I gave up and switched to Oxlint. It functions as a drop-in replacement for ES-Lint, has all this plugin's rules built-in, and config is a dead-simple JSON. Backed by Evan You, and even the Biome founder is a consultant. This is the way.