Consider merging into eslint-plugin-jsx-a11y

Question

Consider merging into eslint-plugin-jsx-a11y

beefancohen opened this issue 6 years ago · comments

Hi folks! Just ran into this and I think it's awesome; thanks for all the work you've done here. I filed https://github.com/evcohen/eslint-plugin-jsx-a11y/issues/287 a while ago to do exactly this. I'm here to ask if you'd consider merging this plugin into one tool.

Why?
At Twitter, we use react-native-web. For us eslint-plugin-jsx-a11y provides little to no support, but sometimes it's useful when we need to fallback to DOM elements for one reason or another. IMO having two packages is a nice separation of concerns, but adds a level of indirection for users who need to rely on both. For one, I didn't see this until at least 10 months later 🤷‍♂️ . I know that at Twitter, we could definitely benefit from using both whether it's one plugin or two.

Proposal
Add these rules to eslint-plugin-jsx-a11y under a native namespace OR add a global setting to eslint-plugin-jsx-a11y to specify platform (web, native, both). I'd prefer namespacing since that allows users to opt-in to any rule that suits their project.

How
Add these rules in the next upcoming minor release with a suggested native config.

I'm suggesting moving to jsx-a11y for two reasons:

Pre-existing support and use.
The name is not restrictive of platform, just syntax. (In hindsight, I wish I had just named it eslint-plugin-accessibility 😄 )

Thoughts?

cc/ @jessebeach @ljharb @necolas @comp615

Jordan Harband · Answer 1 · Tue Oct 16 2018 10:30:56 GMT+0800 (China Standard Time)

I’d be concerned about unnecessary overlap with the web plugin, and also, react-native deps and react-web deps conflicting, or imposing unnecessary requirements on those not using react-native-web.

I think separate plugins/packages is a far better idea. It definitely makes sense though, when possible, to use eslint-rule-composer and shared deps to reduce duplication.

Ethan Cohen · Answer 2 · Tue Oct 16 2018 10:41:16 GMT+0800 (China Standard Time)

I’d be concerned about unnecessary overlap with the web plugin, and also, react-native deps and react-web deps conflicting, or imposing unnecessary requirements on those not using react-native-web.

I'm not quite sure what you mean here. Both plugins are react independent, they just enforce on syntax. I don't believe that we have any references to react in jsx-a11y as dependencies or in the code.

At the very least, would you be opposed to a monorepo? In this case, we can help reduce code duplication and have a one-stop-shop for both packages.

Jordan Harband · Answer 3 · Tue Oct 16 2018 10:45:52 GMT+0800 (China Standard Time)

Despite my general feelings on monorepos, one would be fine here (ideally keeping the current jsx-a11y one, and adding this plugin to it). However, I'd expect the first steps to be, make all necessary changes here to maximize reused code.

J. Renée Beach · Answer 4 · Tue Oct 16 2018 11:05:05 GMT+0800 (China Standard Time)

I'm planning a hack for the CSUN conference (early spring 2019) based around this plugin, to burn down the backlog. If we have tasks to pull independent code (like ARIA checks) into their own modules, I can have folks work on that.

J. Renée Beach · Answer 5 · Tue Oct 16 2018 11:05:34 GMT+0800 (China Standard Time)

I'm in no rush to merge projects :) Seems like a lot of work for a risky payout.

Jen Luker · Answer 6 · Mon Oct 29 2018 23:59:33 GMT+0800 (China Standard Time)

The reason we created our own instead of merging it into eslint-plugin-jsx-a11y is that theirs focuses on react-agnostic web, while this one focuses on react-native, specifically. There is no rule overlap.

Though the eslint dependencies do overlap as we forked from that project originally, npm and yarn consolidate those dependencies into a single reference in node_modules, so there isn't a lot of duplication.