Support eslint v9

[DamienCassou]

eslint 9 is being prepared and comes with a lot of changes impacting users and plugin developers: see https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/ for example.

What is the status of eslint v9 support for eslint-plugin-import?

[ljharb]

Since we don’t even support flat config yet (#2873), and eslint doesn’t provide any replacement for FileEnumerator, I’d say it’ll probably be awhile before we support eslint 9.

[JounQin]

At least we can support using eslintrc on eslint v9 currently.

TODO: compatible with some internal API migration like context vs SourceCode.

[ljharb]

I'd definitely love to add some tests on eslint 9, using the env var that restores eslintrc, so we can get ahead of any needed changes.

[TiagodePAlves]

I made a patch for eslint-plugin-import@2.29.1 (and eslint-plugin-i@2.29.1) that works with pnpm and ESLint v9.0.0-beta.2: https://gist.github.com/TiagodePAlves/8c9b1ed4062a484022f5ebf7ba53a5d5

[ljharb]

@TiagodePAlves thanks, that's helpful! once we have tests running on eslint 9, it shouldn't be too difficult to adapt that patch into something that works on both v9 and older versions.

[G-Rath]

@ljharb fwiw I did a very naive find-and-replace of the context utils we're using in eslint-plugin-jest and it looks like that's all thats needed? specifically also seems that only getSourceCode and getScope are the only two removed context methods being used (or at least out of the rules eslint-plugin-jest is using).

Would you like me to attempt a draft PR? I don't know if I'll have the bandwidth to setup a whole test suite but I figure I can contribute enough to kick start the work 🙂

[ljharb]

@G-Rath that might be the case! The blocker really is setting up tests, unfortunately - if we can get tests working on eslint 9, the rest is something I can probably find time for sooner than later :-)

[ryanblock]

@wojtekmaj well, I'm not a contributor here, but I'd imagine because promoting a fork in an active PR in an actively maintained repo seems entirely unnecessary, and perhaps a bit ridiculous. Everyone appears aligned with making this happen.

[ljharb]

Indeed, posting about an alternative project is spam, in a general sense.

[JoseLion]

In case anyone finds it helpful, I got this plugin working on v9 with the help of a couple of extra dependencies from ESLint designed to provide backward compatibility: @eslint/eslintrc and @eslint/compat.

Fair warning: A lot more code needs to be added! But it works, so.... 🤷🏼‍♂️

import { fixupPluginRules } from "@eslint/compat";
import { FlatCompat } from "@eslint/eslintrc";
import eslintJs from "@eslint/js";
import eslintTs from "typescript-eslint";

const project = "./tsconfig.json";
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
const compat = new FlatCompat({
  baseDirectory: __dirname,
  recommendedConfig: eslintJs.configs.recommended,
});

/**
 * @param {string} name the pugin name
 * @param {string} alias the plugin alias
 * @returns {import("eslint").ESLint.Plugin}
 */
function legacyPlugin(name, alias = name) {
  const plugin = compat.plugins(name)[0]?.plugins?.[alias];

  if (!plugin) {
    throw new Error(`Unable to resolve plugin ${name} and/or alias ${alias}`);
  }

  return fixupPluginRules(plugin);
}

export default eslintTs.config(
  eslintJs.configs.recommended,
  ...eslintTs.configs.recommendedTypeChecked,
  ...compat.extends("plugin:import/typescript"),
  {
    languageOptions: {
      parserOptions: {
        project,
        tsconfigRootDir: import.meta.dirname,
      },
    },
    settings: {
      "import/resolver": {
        typescript: {
          alwaysTryTypes: true,
          project,
        }
      },
    },
    plugins: [
      import: legacyPlugin("eslint-plugin-import", "import"),
      // ...rest of plugins
    ],
    rules: {
      // your rules here....
    },
  },
);

You can avoid the legacyPlugin(..) abstraction if you like, but it works with other plugins as well, so it's a good idea to keep it around while the ecosystem moves to v9.

IMHO, the ESLint plugin ecosystem is getting harder and harder to maintain, and things get worse during major version upgrades. For instance, I usually find myself adding yet another plugin just for a single rule (e.g. eslint-plugin-deprecation). I think trying to consolidate more rules into ESLint and typescript-eslint can help with this, but I might be missing something, so those are just my two cents 🙂