Summary
The current ESLint setup uses the flat config format with @eslint/js, typescript-eslint recommended rules, react-hooks, react-refresh, and custom rule overrides, but the type-checked TypeScript preset is commented out and the React and JSX accessibility plugins do not appear to have their recommended configs applied.
Problem
This leaves a gap in static analysis quality for the codebase. Type-aware rules are often the ones that catch unsafe promises, incorrect narrowing, misused async patterns, and other issues that plain syntax-only linting misses. Registering the React and jsx-a11y plugins without applying their recommended rules also means some common React correctness and accessibility problems may not be flagged during development.
Why this matters
The repository is TypeScript-first and already uses strict compiler options such as strict, noUnusedLocals, and noUnusedParameters, so extending linting to type-aware analysis is a natural next step rather than an architectural change. This would improve local feedback loops and reduce avoidable review churn before code reaches the quality gate or CI.
Proposed scope
- Enable the
typescript-eslint type-checked recommended config in the ESLint flat config.
- Add parser options that point ESLint at the correct TypeScript project configuration so rules can use full type information.
- Apply recommended flat configs for the React and
jsx-a11y plugins rather than only registering the plugins.
- Keep existing project-specific overrides such as
@typescript-eslint/no-explicit-any: warn and react-refresh/only-export-components.
Acceptance criteria
- ESLint runs with type information enabled for app code.
- React recommended lint rules are active.
- Accessibility recommended lint rules are active for JSX.
- The lint script remains fast enough for pre-commit and local development use.
- Documentation is updated if contributors need a different command for full lint vs fast lint.
Suggested implementation notes
- Consider using a dedicated
tsconfig.eslint.json if the main TypeScript config becomes too broad or introduces performance issues.
- Consider separate ESLint overrides for browser code, Node config files, and test files so rule behavior matches execution context.
- If performance degrades, keep a lightweight default lint command and add a stricter CI lint command.
Summary
The current ESLint setup uses the flat config format with
@eslint/js,typescript-eslintrecommended rules,react-hooks,react-refresh, and custom rule overrides, but the type-checked TypeScript preset is commented out and the React and JSX accessibility plugins do not appear to have their recommended configs applied.Problem
This leaves a gap in static analysis quality for the codebase. Type-aware rules are often the ones that catch unsafe promises, incorrect narrowing, misused async patterns, and other issues that plain syntax-only linting misses. Registering the React and
jsx-a11yplugins without applying their recommended rules also means some common React correctness and accessibility problems may not be flagged during development.Why this matters
The repository is TypeScript-first and already uses strict compiler options such as
strict,noUnusedLocals, andnoUnusedParameters, so extending linting to type-aware analysis is a natural next step rather than an architectural change. This would improve local feedback loops and reduce avoidable review churn before code reaches the quality gate or CI.Proposed scope
typescript-eslinttype-checked recommended config in the ESLint flat config.jsx-a11yplugins rather than only registering the plugins.@typescript-eslint/no-explicit-any: warnandreact-refresh/only-export-components.Acceptance criteria
Suggested implementation notes
tsconfig.eslint.jsonif the main TypeScript config becomes too broad or introduces performance issues.