面向 lint 编程
内容提要
文章介绍前端 Linter 生态：Linter 用于检测代码风格与逻辑问题，常见工具有 ESLint、Stylelint，Prettier 是格式化器而非 Linter。以 ESLint 为例，讲解 Parser、配置、共享配置、Plugin、Rule、自动修复等概念及工作原理，并介绍 lint-staged、git hooks、CI 中只检查改动文件、VSCode 插件配置、并发问题，以及 Rust 化、ESM 化趋势和常见踩坑经验。
延伸解读
Linter 与 Formatter 的职责区分
文章明确指出 Prettier 是格式化器而非 Linter，Linter 主要检测代码风格和逻辑问题。ESLint 等 Linter 通过规则发现潜在 bug，而 Prettier 专注于代码格式统一。理解这一区别有助于合理配置工具链，避免功能重叠。例如，ESLint 可配置规则来约束代码风格，但格式化任务应交给 Prettier，两者配合使用能提升开发效率。
ESLint 配置的灵活性与共享
ESLint 支持多种配置文件格式，如 JSON 和 JS，其中 JS 格式可编程性更强，便于复用 npm 生态。共享配置以 npm 包形式发布，通过 extends 继承，如 airbnb 或 standard。插件可提供额外规则和配置，用户配置优先级最高。这种设计让团队能快速统一代码规范，同时保留自定义空间，但需注意配置冲突和优先级管理。
增量 Lint 与 Git Hooks 实践
对于大型项目，全量 Lint 效率低下，lint-staged 可仅检查暂存文件，实现渐进式修复。结合 git hooks（如 pre-commit）触发检查，能及早发现问题。文章提到从 husky 迁移到 simple-git-hooks 的案例，并指出需注意 core.hooksPath 配置，避免钩子不触发。在 CI 中，可自定义脚本实现 lint changed，优化输出和错误处理，提升反馈效率。
Lint 生态趋势与常见陷阱
文章提到 Lint 工具正朝着 Rust 化和 ESM 化发展，如 rslint、rome 等 Rust 工具提升性能，而 ESLint 等对 ESM 配置文件支持仍在推进。实践中需注意并发问题：本地 lint-staged 应串行执行写操作，CI 中可并行只读检查。此外，自动修复可能不安全，如 unicorn/prefer-at 规则在 NodeList 上不适用，需谨慎启用。合理利用 IDE 插件和调试选项能提升体验。
Q&A
ESLint 和 Prettier 有什么区别？
ESLint 是 Linter，用于检测代码风格和逻辑问题；Prettier 是格式化器（formatter），不是 Linter。
ESLint 的 Parser 有什么作用？
Parser 将源码解析成 AST，规则通过遍历 AST 节点发现代码问题。ESLint 默认使用 espree，也可通过配置指定其他 parser，如 @typescript-eslint/parser。
lint-staged 是做什么的？为什么需要它？
lint-staged 用于在 git 提交前只对本次修改的文件进行 lint 检查，避免全量 lint 速度慢，并能渐进式处理代码中的 lint 问题。
ESLint 的自动修复（--fix）有什么安全约定？
自动修复必须确保修复后代码逻辑不变（安全修复）；如果不安全，应提供手动修复建议供 IDE 使用。例如 unicorn/prefer-at 规则将 array[array.length - 1] 修复为 array.at(-1) 可能不安全，因为 NodeList 没有 at 方法。
在 CI 中如何只 lint 改动的文件？
可以自己实现脚本读取 lint-staged 配置，通过 git diff 获取改动文件，再用 micromatch 匹配并执行对应 lint 任务，同时优化输出避免冗余。
ESLint 生态有哪些新趋势？
Rust 化：出现 rslint、rome 等 Rust 编写的 lint 工具，ESLint 也计划部分组件用 Rust 重写。ESM 化：ESLint、Stylelint、Prettier 等工具正在逐步支持 ESM 配置文件。
