Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include accessibility rules #17

Open
sholladay opened this issue Dec 1, 2017 · 11 comments
Open

Include accessibility rules #17

sholladay opened this issue Dec 1, 2017 · 11 comments

Comments

@sholladay
Copy link

Most applications ought to follow accessibility standards to be inclusive and usable for people with disabilities. To that end, there is a fantastic ESLint plugin, jsx-a11y, which provides rules that enforce best practices around accessibility.

Thoughts on using the plugin here?

@sindresorhus
Copy link
Member

This is blocked by eslint/eslint#3458.

@fregante
Copy link
Member

fregante commented Jan 8, 2020

Why? Aren't eslint-plugin-react and eslint-plugin-react-hooks plugins themselves?

@sindresorhus
Copy link
Member

@fregante Yes, but they are plugins everyone would want.

@fregante
Copy link
Member

fregante commented Jan 8, 2020

How would eslint/eslint#3458 solve that?
Wouldn't its resolution mean you can list eslint-plugin-jsx-a11y in eslint-config-xo-react's dependencies?

@sindresorhus
Copy link
Member

Wouldn't its resolution mean you can list eslint-plugin-jsx-a11y in eslint-config-xo-react's dependencies?

A dependency is cheap, but requiring people to manually install stuff is not.

@sindresorhus
Copy link
Member

I wonder if it's possible to expose xo-react/accessibility. I don't think that would require normal users to need to install the accessibility plugin.

@fregante
Copy link
Member

fregante commented Jan 8, 2020

A dependency is cheap, but requiring people to manually install stuff is not.

Doesn't everyone just copy-paste the whole string from the readme? It's already long:

$ npm install --save-dev eslint-config-xo eslint-config-xo-react eslint-plugin-react eslint-plugin-react-hooks

I suppose that the issue here would be for existing users who'd have install eslint-plugin-jsx-a11y when updating eslint-config-xo-react

@sindresorhus
Copy link
Member

Every style guide using this package would have to include install instructions for eslint-plugin-jsx-a11y too.

I suppose that the issue here would be for existing users who'd have install eslint-plugin-jsx-a11y when updating eslint-config-xo-react

This too. I don't want to inconvenience people and force them to install, maintain, and possibly upgrade a plugin they don't want.

@papb
Copy link

papb commented Jun 22, 2020

Every style guide using this package would have to include install instructions for eslint-plugin-jsx-a11y too.

Perhaps it is possible to work around this by trying to require eslint-plugin-jsx-a11y and silently skipping its rules if it is not found, instead of crashing?

@GriffinSauce
Copy link

Yes, but they are plugins everyone would want.

This too. I don't want to inconvenience people and force them to install, maintain, and possibly upgrade a plugin they don't want.

This logic locks you into never adding another plugin right? That doesn't sound very constructive.

The idea with XO is to be opinionated, when you let optionality take precedent you're breaking that philosophy and people might as well just go back to copy-paste-tweaking ESLint configs.

Accessibility needs people to be opinionated in its favour. Skipping it is a path of lazyness that we as a community take far too often. I urge you to take a stand and say "XO supports a11y - if you want to built inaccessible things this is not the tool for you".

@sholladay
Copy link
Author

sholladay commented Jun 29, 2020

Perhaps it is possible to work around this by trying to require eslint-plugin-jsx-a11y and silently skipping its rules if it is not found, instead of crashing?

I'd rather it be required. But if it had to be optional, a warning should still be printed to avoid silent accidental failure.

Regardless, my understanding is that configs cannot directly import plugins. So I don't think it's even possible to make it optional. Edit: Actually, you're right, a try / catch around the import would probably work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants