Add support for ESLint 9

[jacobcarpenter]

ESLint 9 is released, but it looks like eslint-plugin-jsx-a11y does not yet support it.

There are breaking API changes: https://eslint.org/docs/latest/use/migrate-to-9.0.0#breaking-changes-for-plugin-developers

There is also a new default config format ("flat config") that probably also needs some adjustment in the exported recommended rules; though, support for flat config could be considered a separate issue.

[ljharb]

Yes, that's right.

In eslint 9, RuleTester only supports flat config, so it makes things more complicated.

I think we need flat config support before we have eslint 9 support.

[ljharb]

See #891.

[guswnsxodlf]

I'm using the plugin with the flat config.
Hope it fully supports eslint flat config asap! 👍🏻

import pluginJsxA11y from 'eslint-plugin-jsx-a11y';

export default [
  ...
  {
    plugins: {
      'jsx-a11y': pluginJsxA11y,
    },
    rules: pluginJsxA11y.configs.recommended.rules,
  },
  ...
];

[ljharb]

#993 adds support for flat config, so in theory, we're now unblocked from supporting eslint 9.

[ljharb]

@pauliesnug please note that TS's module system is horrifically broken unless you enable synthetic imports and esModuleInterop - you shouldn't see an issue with the default import that way.

[eagerestwolf]

@pauliesnug that's got nothing to do with eslint 9. we could certainly do that - to help plugin developers, but it seems like you mean so that users have types for the flat config objects?

Yes, and for importing the plugin itself.

// @ts-check

// Not only does this throw a typing error, but also a default import error
import jsxA11y from 'eslint-plugin-jsx-a11y';

export default [jsxA11y()];

You are getting an import error because eslint-plugin-jsx-a11y doesn't ship type definitions. It has absolutely nothing to do with TypeScript's module system, which works perfectly fine so long as library developers ship standard modules with types. Otherwise, yes it misbehaves. To make the import error go away just create a .d.ts file (traditionally, global.d.ts) with the following content.

declare module "eslint-plugin-jsx-a11y";

Note that you will continue to get type errors everytime you do anything with jsxA11y because it's an untyped module. TypeScript doesn't know what it is, so it assumes it's any (which is bad). You're getting a syntax error because what you imported is an object, not a function.

[ljharb]

(if you're going to make type defs, please do so in DefinitelyTyped, so others can benefit)

[pauliesnug]

(if you're going to make type defs, please do so in DefinitelyTyped, so others can benefit)

good idea, i'll do that until they are shipped alongside the plugin

[eagerestwolf]

@ljharb done DefinitelyTyped/DefinitelyTyped#70203. Once the PR is merged, it should now be possible to do the following (and by it should, I mean I am using this):

import { fixupConfigRules } from "@eslint/compat";
import jsxA11y from "eslint-plugin-jsx-a11y";

export default [
  // Other configs here
  ...fixupConfigRules(jsxA11y.flatConfigs.recommended),
];

[eagerestwolf]

@ljharb @pauliesnug If either of you would like to double check the PR and make sure I typed everything correctly, you are welcome to do so.

[eagerestwolf]

You are correct in that sense, but its ultimately a personal preference thing. I guess the main differentiation for me is developer experience, whereas yours is user experience. There is nothing wrong with JSDoc commented pure JS, except that it causes headaches for TS users because TS really doesn't like untyped things. Ultimately, an ideal solution is probably both good JSDoc comments and TS. JSDoc allows JS users to get the advantages of type awareness (not the same as type checking), while TS users get their type safety.

Yes, you are correct that there are some TS options that negate some (not all, don't conflate the 2) type safety features. However, that's intended. One of the nice things about TS is that you, as the developer, decide how you consume and compile your code.

As for Svelte, another reason for not using TS (especially in very large projects) is TS's compiler is not fast (and anyone who says it is is lying to you). That's not the only reason Svelte is going pure JS though. That move is also part of Svelte's push to embrace standards as they are, and not to meddle with them like other frameworks do. That is once of the things that made Svelte popular, and why it's still so loved.

Ultimately, we can agree to disagree. However, there is another alternative to pure TS and pure JS. You could simply pass your pure JS into the TS compiler and it will spit out as .d.ts file using your JSDoc annotations to infer types. With that said, I can tell this conversation is going nowhere. We are running in circles. The people who work on this project don't like TS, and that's fine. However, there are many of us that do. You can continue to work in JS and Flow, and if the community decides to create a TS fork, the community decides to create a TS fork. That's the beauty of open source.

This will be my last comment on this issue. I see no point in discussing it further.

[ljharb]

Consumers can’t tell the difference between a TS project, a JS project with JSdoc types, or a typeless project with DT types.

The contributor experience for the first two is largely identical as well.