深入理解 lint-staged 对已删除文件的处理机制

在 Git 工作流中，lint-staged 是一个非常有用的工具，它允许我们在提交代码前对暂存区的文件运行指定的脚本。然而，许多开发者可能没有意识到，lint-staged 默认情况下不会处理已被删除的文件，这可能导致一些潜在问题。

lint-staged 默认行为解析

lint-staged 默认使用 --diff-filter=ACMR 参数来筛选文件，这意味着它只会处理：

• 新增的文件 (A)
• 复制的文件 (C)
• 修改的文件 (M)
• 重命名的文件 (R)

值得注意的是，已删除的文件 (D) 不在默认处理范围内。这种设计是有意为之的，因为大多数常用的代码检查工具（如 ESLint 和 Prettier）在处理不存在的文件路径时会出现问题。

实际开发中的潜在风险

在实际开发场景中，这种默认行为可能导致以下问题：

1. 构建系统不一致：当删除源文件时，构建脚本不会执行，可能导致 dist 目录中的旧文件未被清理
2. 类型检查遗漏：删除类型定义文件时，类型检查可能不会运行
3. 自动化流程中断：依赖文件删除触发的后续操作不会执行

解决方案与最佳实践

要解决这个问题，我们可以通过以下方式调整 lint-staged 的行为：

1. 修改 diff-filter 参数：在运行 lint-staged 时添加 --diff-filter=ACMRD 参数，使其包含已删除的文件
2. 特殊处理删除操作：对于需要特别关注文件删除的场景，可以添加专门的检查逻辑
3. 结合 Git 钩子：在 pre-commit 钩子中显式检查文件删除情况

实际配置示例

对于需要处理文件删除的场景，可以这样配置 lint-staged：

// .lintstagedrc.js
module.exports = {
  './src/**/*': (filenames) => {
    const deletedFiles = filenames.filter(f => !fs.existsSync(f))
    const existingFiles = filenames.filter(f => fs.existsSync(f))
    
    return [
      ...(deletedFiles.length ? ['echo "处理删除文件"', 'npm run clean-deleted'] : []),
      ...(existingFiles.length ? ['npm run build'] : [])
    ]
  }
}

总结

理解 lint-staged 对已删除文件的处理机制对于维护健壮的开发工作流至关重要。虽然默认行为对大多数场景是合理的，但在涉及构建系统或需要严格文件管理的项目中，开发者应该主动调整配置以确保所有变更（包括文件删除）都能触发相应的处理流程。

通过合理配置，我们可以确保代码库在各种变更情况下都能保持一致性，避免因文件删除导致的构建产物不一致等问题。