Research Spike: ESLint 9 compatibility

[ChristianMurphy]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

ESLint 9 is changing the plugin API: https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/
There may be changes needed in ESLint-MDX

Solution

Check to see if any changed/removed APIs are used, migrate if needed.

Alternatives

• No change may be needed
• We could remain on eslint 8 for a while if the migration is challenging

[JounQin]

I don't see how to test eslint@9 at this point.

[ChristianMurphy]

https://github.com/eslint/eslint/releases/tag/v9.0.0-alpha.0

[remcohaszing]

Since the new flat config no longer resolves files, and supports eslint.config.mjs, I think ESLint MDX integrations can switch to ESM.

[JounQin]

Since the new flat config no longer resolves files, and supports eslint.config.mjs, I think ESLint MDX integrations can switch to ESM.

I'd like to keep dual. Legacy .eslintrc configs are still supported.

[ChristianMurphy]

Legacy configuration are deprecated https://eslint.org/blog/2023/12/eslint-v9.0.0-alpha.0-released/

There are far less quirks and hacks packaging as pure ESM, rather than dealing with dual packaging limitations.

[JounQin]

#496

@ChristianMurphy

worker.mts will bypass all the limitations.

They're deprecated but still supported. I don't want to break anyone's current workflow before they're ready including myself.

For example, compatibility with other plugins.

import-js/eslint-plugin-import#2948 (comment)

[tianyingchun]

What's the plan?

[karlhorky]

If you don't use Markdown, then the current version [email protected] appears to work in ESLint v9 by copying the flat config which is exported:

eslint.config.js or eslint.config.mjs

import eslintMdx from 'eslint-mdx';
import mdx from 'eslint-plugin-mdx';

/** @type {import('eslint').Linter.FlatConfig} */
const config = [
  {
    files: ['**/*.mdx'],
    languageOptions: {
      sourceType: 'module',
      ecmaVersion: 'latest',
      parser: eslintMdx,
      globals: {
        React: false,
      },
    },
    plugins: {
      mdx,
    },
    rules: {
      'mdx/remark': 'warn',
      'no-unused-expressions': 'error',
      'react/react-in-jsx-scope': 0,
    },
  },
];

export default config;

[tianyingchun]

i have integrating mdx into a plugin it can works fine for eslint V9
https://github.com/hyperse-io/eslint-config-hyperse

[tianyingchun]

what's plan for ESLint V9, i used it in local, it seems that everything works fine except we need to bump eslint-plugin-markdown to latest version (5.1.0) for now it used "eslint-plugin-markdown": "^3.0.1"?

[reduckted]

ESLint v8 is EOL in one month (https://eslint.org/version-support/). Would you consider dropping v8 support to make it easier to migrate this plugin to v9?

If anyone really needs v8 support, they can continue to use the current version of this plugin.

[remcohaszing]

@eslint/markdown (formerly eslint-plugin-markdown 6.0.0 is ESM only. I think it’s fair to drop CJS support in other ESLint plugins as well.

[tianyingchun]

it's time to drop cjs +1 :)

[terrymun]

I'm wondering what's the state of adding eslint 9 (and @eslint/markdown) compatibility? AFAIK @eslint/markdown is already at version 6 and the one used by eslint-mdx is three major versions behind.

[JounQin]

I believe it's working fine with ESLint v9 currently.

PR welcome to bump deps without dropping ESLint v8 for now except there are great features we want but incompatible.

[reduckted]

@JounQin What is the reason for wanting to keep ESLint V8 support?

[JounQin]

Clearly there are still 50%+ eslint v8 users.

[reduckted]

Can't those users keep using v3.1.5 of this package? ESLint V8 has been EOL for many months now, and it's not like they'd be missing out on new features since v3.1.5 was released 12 months ago.

I'm just thinking of ways to reduce the complexity and maintenance burden of trying to support ESLint v8 and v9 at the same time. 😄

[bodograumann]

Exactly, @reduckted . This all-or-nothing approach was also taken by the vue libraries. They simply released a new major version compatible only with eslint-9 and for eslint-8-support you had to use the old versions.
I think at this point anything fixing anything hindering upgrade should be the priority. We had to drop eslint-mdx to be able to do that.

[JounQin]

I think at this point anything fixing anything hindering upgrade should be the priority. We had to drop eslint-mdx to be able to do that.

I don't get what's the issue here, what blocks using eslint-mdx with ESLint v9 + other plugins?

[terrymun]

I agree with @reduckted and @bodograumann that a major version release of eslint-mdx that exclusively supports eslint@9 + @eslint/markdown@6 is probably the best way forward.

Right now we have to ignore error messages when consuming this eslint plugin because it consumes an outdated version of eslint-markdown that does not support react19.

[JounQin]

Right now we have to ignore error messages when consuming this eslint plugin because it consumes an outdated version of eslint-markdown that does not support react19.

Maybe this is something as I mentioned:

except there are great features we want but incompatible.

@terrymun Do you have any reproduction of such issues?

[terrymun]

@JounQin Ah my bad, I mixed up react19 and eslint9.

When installing eslint-plugin-mdx, you'd get an unmeet peer dependency warning if you're using it in a stack that uses eslint 9:

[JounQin]

PR welcome to

1. bump eslint-plugin-markdown to v5.1.0 which supports both eslint v8 and v9
2. Considering mdx/code-blocks doesn't respect eslint-disable from outside of the block #534 (comment), we can copy related processor codes from eslint-plugin-markdown and drop it as dependency

And also, I'm unsure how far would eslint/markdown#316 go