ESLint

Commands

Task	Command
Lint everything	pnpm lint
Lint only ESLint	pnpm lint:eslint
Lint a specific file	pnpm exec eslint <path>
Lint with auto-fix	pnpm exec eslint --fix <path>

Default action: When asked to "lint" or "run ESLint" without further qualification, run pnpm lint.

Before linting — explore the project first

Before running or modifying ESLint, read the project's eslint.config.mjs to understand:

• Which plugins and extends are active (e.g. typescript-eslint, angular-eslint, eslint-plugin-storybook)
• Which files and globs are covered or ignored
• Which rules are customized beyond the recommended defaults
• Whether type-aware linting is enabled (parserOptions.projectService: true) — this requires a valid tsconfig.json
• How eslint-config-prettier is applied (it must be the last entry to correctly disable formatting rules)

Also check package.json scripts to understand what pnpm lint and pnpm lint:eslint actually invoke for this specific project — the command and glob patterns vary across repos.

Configuration format

All projects use the ESLint 9 flat config (eslint.config.mjs). The legacy .eslintrc.* format is not used. When writing or modifying configs, always use defineConfig and globalIgnores from eslint/config.

Relationship with Prettier

ESLint and Prettier have a strict separation of concerns:

• ESLint — code quality, type safety, framework-specific rules
• Prettier — all formatting (indentation, quotes, line length, trailing commas, etc.)
• eslint-config-prettier is always the last config entry to disable ESLint rules that conflict with Prettier

Never add formatting rules to ESLint. Never use eslint --fix to fix formatting — use pnpm format:write instead.

Import organization is handled exclusively by Prettier (prettier-plugin-organize-imports) — do not introduce ESLint import-sorting plugins.

Workflow notes

• Run pnpm lint before every commit alongside pnpm format:write
• If lint fails in CI, fix the issues locally and confirm with pnpm format:write && pnpm lint before committing
• Prefer fixing the root cause over disabling rules with eslint-disable comments
• When disabling a rule is truly necessary, use the most targeted scope (single line > block > file) and add a comment explaining why