eslint-fix

ESLint Fix Assistant

Workflow

1. Identify the project toolchain

Read:

• package.json scripts in,devDependencies and packageManager。
• the lockfile for npm, pnpm, Yarn, or Bun.
• eslint.config.*、.eslintrc.*、.eslintignore, Prettier, and TypeScript configuration.
• Applicable repository rules, Git status, and the file scope specified by the user.

Prefer running the repository's existing lint script. Only when it is confirmed that ESLint is locked and installed by the current project, use the corresponding package manager's local execution method. If dependencies are missing, report first; installing packages, updating the lockfile, or migrating configuration requires separate authorization.

2. Establish a read-only baseline

First run a non-file-modifying check on the scope specified by the user or relevant to this round, and record:

• The actual command, ESLint version, and exit status.
• The number of errors / warnings, the files involved, and the rules.
• Issues already present in the baseline and issues introduced in this round.

Do not scan the entire large repository by default, and do not use unlocked dependencies or npx invocations that may download a new version over the network.

3. Preview the fixable scope

• Use the --fix-dry-run, JSON output, or equivalent capability supported by the project's existing commands to determine the expected changes.
• Check the current Git diff to confirm that the target files do not overlap with the user's modifications.
• Distinguish three categories of issues: auto-fixable, those requiring understanding of code semantics, and those requiring configuration decisions.
• Show the expected scope of changes; obtain confirmation first if it may produce a large-scale formatting diff or change logic.

4. Scoped fixes

• Only run --fixon confirmed files, and do not automatically expand to the entire repository.
• For semantic rules such as no-explicit-any, unhandled Promises, and React Hooks dependencies, modify based on types, callers, and execution paths; do not perform mechanical replacements.
• Do not disable rules by default, add global ignores, change formatter order, or lower severity levels just to eliminate errors.
• The execution order of Prettier and ESLint is based on the project's existing scripts and integration configuration.

Common auto-fixable rules include semi、quotes、indent、no-trailing-spaces、comma-dangle、arrow-parens and prefer-const; dry-run and diff can only preview changes, and in the end type checks, tests, or builds still need to be run according to risk.

5. Re-verify

After the actual modifications:

1. Re-run lint on the target scope.
2. Run type checks, relevant tests, or builds according to the risk of the changes.
3. Review the Git diff to confirm there are no lockfile, generated artifact, or unrelated formatting changes.
4. Record unresolved rules, the reasons, and recommended next steps.

Safety boundaries

• Without explicit authorization, do not install or upgrade dependencies, and do not modify the lockfile, ESLint configuration, Prettier configuration, or project scripts.
• Do not overwrite existing modifications in the working tree; report first if there is overlap in the target files.
• Do not claim "fixed" or "compiles" unless the corresponding command has actually been run and succeeded.
• On both Windows and Linux, prefer the project's existing scripts and paths, and do not hardcode shell-specific commands.

Output

## ESLint 检查结果

- 范围：
- ESLint / 包管理器版本：
- 基线：X error，Y warning
- 实际命令与退出状态：

## 修改

| 文件 | 规则 | 处理方式 |
|------|------|----------|

## 复验

- lint：
- 类型检查 / 测试 / 构建：
- 未解决问题与原因：