eslint-plugin-jsx-a11y
eslint-plugin-jsx-a11y copied to clipboard
Add support for ESLint 9
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.
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.
See #891.
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,
},
...
];
Any update on adopting this?
#993 adds support for flat config, so in theory, we're now unblocked from supporting eslint 9.
In addition to ESLint v9 support, we should add TypeScript definitions in the package for typechecking the plugin.
@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?
@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()];
Since eslint@9 was not included in peerDependencies, I submitted a PR (https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/pull/994) to fix it.
@yuheiy as i commented there; that's nowhere near sufficient to get this support shipped, but please leave the PR open.
@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.
@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.
(if you're going to make type defs, please do so in DefinitelyTyped, so others can benefit)
(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
@ljharb done https://github.com/DefinitelyTyped/DefinitelyTyped/pull/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),
];
@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.
On the topic of having a stopgap soon. Would there be interest in assistance in a rewrite to support ESLint 9? I will say if I would be the one to really help push this forward, I have some ideas as to how that would be accomplished. First, the plugin should probably be written in TypeScript using @typescript-eslint/utils which already has native support for JSX (and typed linting as well, not that it's really super necessary for this project), thus negating the need for the custom JSX library. This would also allow dropping the external types repo, since you could just ship your own types. Additionally, a major rewrite (which would almost certainly result in a V7 release) would be a great time to remove any already deprecated rules. This is how I would tackle the rewrite; but it's your project. I will just say if it's going to in pure JS (or worse Flow), I have no interest in helping.