Roadmap (beta)

[43081j]

as part of providing lighter alternatives for popular lint plugins with deep compat layers, this project should provide an alternative to the jsx-a11y plugin.

At a high level, I don't think we should fork the plugin as it contains a large amount of support code for older runtimes and a plugin system we don't necessarily need.

Instead, we can do similar to lit-a11y - start from scratch but try to support the same rule set (as best we can / where appropriate).

The existing plugin's rules can be found here:

https://github.com/jsx-eslint/eslint-plugin-jsx-a11y?tab=readme-ov-file#supported-rules

Basic requirements

• All non-deprecated rules supported (unless we decide not to support one through discussion)
• Both eslintrc and eslint config files supported
• Specific to JSX (i.e. we don't need to care about supporting HTML strings etc)
• No node compatibility dependencies (polyfills, "polyfills", etc)

Open questions

• What version of ESLint do we require? 8.x onwards?

Contributors/Owners

I think we can start by contributing a rule each over time, and naturally will end up with a couple of us owning this repo (but anyone can contribute one).

I'll also start a discussion on discord (e18e) to discuss this

cc @MichaelDeBoey

[MichaelDeBoey]

I personally would say that it would be better to start from a fork and remove all unnecessary things piece by piece tbh
That way it's imo way easier to stay up to date with upstream

As for me this fork should just be "an exact fork, but without the Node 4 support BS"

[SukkaW]

I personally would say that it would be better to start from a fork and remove all unnecessary things piece by piece tbh That way it's imo way easier to stay up to date with upstream

As for me this fork should just be "an exact fork, but without the Node 4 support BS"

Hi, the current maintainer of eslint-plugin-import-x here. eslint-plugin-import-x started as eslint-plugin-i, where we initially forked and removed unnecessary polyfills. However, we've since moved on. We've used TypeScript to completely rewrite the entire codebase and have started to deviate from eslint-plugin-import.

In my opinion, if we're going to do this, we should do it thoroughly.

[MichaelDeBoey]

@SukkaW Can you elaborate on what deviations did happen in that fork?

[SukkaW]

@SukkaW Can you elaborate on what deviations did happen in that fork?

The most notable is that ljharb has hundreds of PRs piled up without reviewing or merging any of them. We want to backport many PRs to eslint-plugin-i while maintaining the sync with the upstream, but it becomes increasingly harder to keep in sync with the upstream. It turns out that we'd better deviate from the upstream. So we changed the name from eslint-plugin-i to eslint-plugin-import-x.

[benmccann]

As for me this fork should just be "an exact fork, but without the Node 4 support BS"

I see you've been active in the upstream eslint-plugin-jsx-a11y and all the Node 0.4 stuff has been removed now. Do we still need a fork in that case? eslint-plugin-import has 89 unmerged PRs, so I see why it would be forked to get in missing features. eslint-plugin-jsx-a11y has only 21 and most are fairly recent

[43081j]

yes, since the posting of this, jsx-a11y has stripped away all of the node compat stuff

however, it likely still depends on the global mutation protection stuff (i.e. using a wrapped function for most built ins to avoid people mutating them and breaking the code). we likely don't need those in our case, so it may still be a good idea to create an alternative as they probably account for a lot of the dependency tree (Though I haven't checked, so please do if you get chance)

[MichaelDeBoey]

@43081j I'm not sure which things you had in mind, but we did already remove usage of array-includes, array.prototype.flatmap, hasown, object.assign, object.entries, object.fromentries & string.property.includes.

Next to that we also changed engines.node support to ^20.18 || ^22.10 || >= 23 and ESLint support to ^8.57.0 || ^9.13.0.

I'm happy to create extra PRs if you can explain what thing you would like to see changed as well

[benmccann]

It looks like the jsx-ast-utils dependency is quite problematic and would need to be cleaned up as it still pulls in all the polyfills. The safe-regex-test dependency isn't as bad, but could probably be slimmed down som as well.
https://npmgraph.js.org/?q=jsx-ast-utils
https://npmgraph.js.org/?q=safe-regex-test

[MichaelDeBoey]

@ljharb Is it worth it to create PRs for updating these 2 libraries as well?
Or are those 2 libraries absolutely not going to release a major version, even if I create PRs to update them?

Just so I know if it's worth my time spent updating these 2 libs

---

Edit: @benmccann I've already created jsx-eslint/jsx-ast-utils#141 & jsx-eslint/jsx-ast-utils#142.

Are there any other changes you would like to see in this library?

[ljharb]

safe-regex-test won’t be dropping anything, but jsx-ast-utils might, after the major bump, if it has no dependents left that need it.

As for the PRs claim, the import plugin has 89 open PRs, and the vast majority have in fact been reviewed. I don’t think the hyperbole helps anyone.

[SukkaW]

safe-regex-test still has dependencies like set-function-length, has-tostring-tag, has-symbols, has-proto, hasown, es-errors, function-bind, and many more. So "won't be dropping anything" is a very disappointing statement here.

[ljharb]

Yes, it still needs all those dependencies for the range of environments it’s intended for.