-
-
Notifications
You must be signed in to change notification settings - Fork 636
[suggestion] eslint auto-fix support? #951
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
Comments
Not everything needs to be, nor should be autofixable. That said, anything that's safe to autofix should be autofixed. If there's a finite number of correct options, and the user has to choose, suggestions are appropriate. Is there something specific you have in mind? |
@ljharb makes sense. I was thinking about the interactivity rules, for example
would yield both
|
Selecting a tabIndex definitely isn't a safe autofix, but it could be a suggestion. As for the |
Do you think its implausible to get a solution that is or approaches correct? Anything with an I'm not super navigating and asserting on the AST, but seems like this should be possible to write code to do this? |
I think that it is strictly inappropriate for an eslint rule to be that loose; autofixes must always be safe - no false corrections - and suggestions only make sense when there's a few correct options the user should pick from. Beyond that, users can just write the code, it's not that big a deal :-) |
Thanks @ljharb, the use case I was thinking about was a global autofix via @ljharb if you want I can create a followup issue for suggesting |
You can definitely make your own plugin and rule, that composes this one and adds your own autofixes. No need for an issue if you want to just make a PR :-) otherwise an issue is fine. |
Thanks, makes sense. We're currently using For the suggestion, I will create an issue for my own sake, to track the work since it might be a bit before I implement something. |
Add basic support for Eslint rule suggestions for the `interactive-supports-focus` for tabIndex values when elements are interactive but do not have implicit focusable browser behaviour. These are intentionally not auto-fix but simply optional suggestions to help developers resolve their issue. Fixes jsx-eslint#952 See also jsx-eslint#951
Add basic support for ESlint rule suggestions for the `interactive-supports-focus` for tabIndex values when elements are interactive but do not have implicit focusable browser behaviour. These are intentionally not auto-fix but simply optional suggestions to help developers resolve their issue. Fixes jsx-eslint#952 See also jsx-eslint#951
Add basic support for ESlint rule suggestions for the `interactive-supports-focus` for tabIndex values when elements are interactive but do not have implicit focusable browser behaviour. These are intentionally not auto-fix but simply optional suggestions to help developers resolve their issue. Fixes jsx-eslint#952 See also jsx-eslint#951
Add basic support for ESlint rule suggestions for the `interactive-supports-focus` for tabIndex values when elements are interactive but do not have implicit focusable browser behaviour. These are intentionally not auto-fix but simply optional suggestions to help developers resolve their issue. Fixes jsx-eslint#952 See also jsx-eslint#951
Add basic support for ESlint rule suggestions for the `interactive-supports-focus` for tabIndex values when elements are interactive but do not have implicit focusable browser behaviour. These are intentionally not auto-fix but simply optional suggestions to help developers resolve their issue. Fixes jsx-eslint#952 See also jsx-eslint#951
Add basic support for ESlint rule suggestions for the `interactive-supports-focus` for tabIndex values when elements are interactive but do not have implicit focusable browser behaviour. These are intentionally not auto-fix but simply optional suggestions to help developers resolve their issue. Fixes jsx-eslint#952 See also jsx-eslint#951
Hi folks, thanks for all the hard work on this. I've been thinking about support for auto-fixing, if only to illustrate possible approaches to developers on how to fix accessibility issues. I didn't see any discussion in past issues so putting it out there.
I think the challenge to auto-fixing might be defining what "correct" looks like for many categories of failure, but maybe worth a try to at least present partial fixes?
Curious to hear your thoughts or any pointers to previous discussions i might've missed. Thanks!
The text was updated successfully, but these errors were encountered: