Trade‑off: vite-plugin-eslint with eslint-plugin-jsx-a11y vs vite-plugin-a11y for dev‑time accessibility checks

Answers to the Core Questions

• Which plugin results in lower HMR latency on a typical 10‑component SPA? vite‑plugin‑eslint + eslint‑plugin‑jsx‑a11y is likely to have lower or comparable latency because the linting work is performed on the source tree and can be cached. vite‑plugin‑a11y runs axe‑core against the rendered DOM on every HMR cycle, which introduces additional JavaScript execution and DOM traversal that can add 50–200 ms to a reload, depending on the size of the updated component.
• Does vite‑plugin‑a11y detect JSX‑specific accessibility issues as reliably as eslint‑plugin‑jsx‑a11y? No. vite‑plugin‑a11y only sees the final DOM after React has rendered it. It will catch runtime‑only problems (e.g., dynamic aria‑hidden, focus traps) but will miss static JSX violations such as missing alt on <img>, incorrect role assignments, or improper button/anchor semantics that eslint‑plugin‑jsx‑a11y flags during static analysis.
• How does the ESLint configuration requirement affect onboarding compared to the zero‑setup axe‑core plugin? vite‑plugin‑a11y requires no ESLint setup, so new developers can start seeing instant DOM‑level reports immediately. However, they miss out on editor‑side linting and the broader rule set of eslint‑plugin‑jsx‑a11y. vite‑plugin‑eslint adds a one‑time ESLint configuration (typically .eslintrc.js or a flat config) and the need to install the eslint‑plugin‑jsx‑a11y package. Once in place, it offers continuous feedback in the editor, terminal, and Vite dev server, which is valuable for long‑term code quality.

Why the Trade‑Off Exists

ESLint with eslint‑plugin‑jsx‑a11y performs static analysis on the JSX source. It is fast, cacheable, and can be integrated into the editor, but it cannot see what actually renders after React’s reconciliation. vite‑plugin‑a11y runs axe‑core against the rendered DOM on every HMR update, delivering real‑time, runtime‑level feedback. The cost is extra JavaScript execution and DOM traversal, which becomes noticeable as the application grows.

Recommended Approach for a Medium‑Size React SPA

1. Start with vite‑plugin‑eslint + eslint‑plugin‑jsx‑a11y. Install the ESLint packages, create a minimal .eslintrc.js that extends plugin:jsx-a11y/recommended, and add the plugin to Vite’s plugins array.

   import eslint from 'vite-plugin-eslint';
   
   export default {
     plugins: [
       eslint({
         cache: true,
         include: ['src/**/*.tsx'],
         emitWarning: true
       })
     ]
   };
   

2. Optional: Add vite‑plugin‑a11y for runtime checks. If you need to surface accessibility issues that only appear after state changes (e.g., dynamic aria‑hidden), add the plugin with a narrow include path or debounce options:

   import a11y from 'vite-plugin-a11y';
   
   export default {
     plugins: [
       a11y({
         include: ['src/**/Page*.tsx'],
         debounce: 300
       })
     ]
   };
   

3. Measure HMR latency. After adding each plugin, edit a component and record the time from keystroke to full reload using the browser’s Performance tab or a simple console timer.
4. Verify JSX rule coverage. Add a contrived component with a missing alt on an <img> and a div role="button" without keyboard handlers. Confirm that eslint‑plugin‑jsx‑a11y reports the errors immediately, while vite‑plugin‑a11y only reports the role issue if the element is mounted.

Missing Diagnostic Detail Needed for Final Recommendation

Could you confirm whether your project uses the ESLint flat config format (eslint.config.js) or the legacy .eslintrc JSON/YAML? The plugin’s integration and caching behavior differ between the two, which may influence latency measurements.