pretty-quick VS eslint-plugin-jsx-a11y

recently my team started facing this issue about pretty-quick not compatible with [[email protected]](mailto:[email protected]). (https://github.com/azz/pretty-quick/issues/164)

If you'd like, you can go a bit further and automate the linting and formatting process a bit. I like to use Husky which allows you to run your linter, tests etc. on a git commit/push etc. You can also then use pretty-quick along with husky to automatically format your code whenever you git commit, just in case someone on your team hasn't set it up in their IDE.

By using husky and pretty-quick, you can automatically force every developer to format all the changed files (and nothing more) every time they commit.

Set up commit hooks with pretty-quick and husky. First, install them as dev dependencies:

In this tutorial, we will also use commitlint and pretty-quick libs to check if your commit messages meet the conventional commit format and run prettier on changed files respectively.

So basically husky is "Git hooks made easy" and we are going to use to automatically format all of our code that is staged for our commits, so we are going to use the "pre-commit" hook to run pretty-quick a simpler way to run our prettier scripts with configuration

I try to focus on the issues rather than individuals, but the root of the problems in the listed eslint plugin libraries points to ljharb.

If you do some simple digging into these libraries, you will find that these types of commits are quite common within them.

https://github.com/jsx-eslint/eslint-plugin-react/commit/e1d...

https://github.com/jsx-eslint/jsx-ast-utils/commit/bad51d062...

https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/commit/...

He would rather see the download count of these polyfill libraries https://github.com/ljharb/ljharb#projects-i-maintain increase, compared to assessing the health of the JavaScript ecosystem.

jsx-a11y is all about ensuring your DOM elements are accessible. This plugin will prompt you to include the correct ARIA attributes such as labels and roles, in addition to things like alt text.

You can also add ESLint now (props to @femincan for the suggestion). It comes with recommended settings for these plugins: typescript, prettier, react, react-hooks, jsx-a11y.

WAI-ARIA is important if you are writing custom components and do not follow the general rules for HTML tags. For example, if you are using a `div` as a button, you would need to add tags for accessibility. Yes, there are some other instances, like adding alt text to images or adding a title to an iframe, but these can all be handled with warnings in the editor using the jsx-a11y eslint plugin. Some other nuance will be up to the developer to make sure they follow the proper accessibility structure, but most use cases are outlined in the Daisy UI tailwind examples, they do a great job of using HTML properly and give fully accessible examples for their components. Take a look at the accordion example, you can tab into the accordion and use the arrow keys to navigate.

jsx-a11 (ESLint plugin) checks a couple other things.

When using react, I've been using the recommended rules from eslint-plugin-jsx-a11y. Am I naive for relying a lot on that to get a11y right? Of course I try to write semantic html too and do research for each topic, but it's a bit overwhelming and I feel like the eslint rules help me a lot.

I found the documentation but no solution here: https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/docs/rules/label-has-associated-control.md

eslint-plugin-jsx-a11y: Checks for accessiblity issues.

For example, Deque's open-source Axe project can help identify issues such as common HTML semantic errors, contrast problems, and more. There are even libraries that help integrate Axe into your project's linters, such as one for React called eslint-plugin-jsx-a11y.