search

es-tooling / eslint-plugin-jsx-a11y-x

An ESLint plugin to apply various a11y rules to JSX templates
MIT License
9 stars 0 forks source link

Roadmap (beta) #1

Open 43081j opened 4 weeks ago

43081j commented 4 weeks ago

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

Open questions

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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

SukkaW commented 3 weeks ago

@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 commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

@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 commented 2 weeks ago

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 commented 2 weeks ago

@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 https://github.com/jsx-eslint/jsx-ast-utils/pull/141 & https://github.com/jsx-eslint/jsx-ast-utils/pull/142.

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

ljharb commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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