解决lint-staged中tsc命令无法正确识别tsconfig的问题

问题背景

在使用lint-staged进行代码提交前的类型检查时，许多开发者会遇到一个奇怪的现象：当直接在lint-staged配置中使用tsc命令时，TypeScript编译器会错误地将每个待检查文件路径后追加/tsconfig.json，导致无法正确找到项目的TypeScript配置文件。

问题现象

开发者通常会在package.json中这样配置lint-staged：

"lint-staged": {
  "*.{ts,tsx}": [
    "npx tsc -b --verbose"
  ]
}

运行后会发现tsc报错，提示类似packages/components/tabs/src/TabsGroup.stories.tsx/tsconfig.json这样的路径找不到。这是因为lint-staged默认会将匹配到的文件列表附加到命令后面。

问题原因

lint-staged的设计初衷是对暂存区的文件逐个进行处理，因此默认情况下它会将匹配到的文件列表作为参数传递给配置的命令。这对于大多数linter工具(如ESLint、Stylelint)是合理的，因为这些工具通常支持接收文件列表作为参数。

但对于TypeScript编译器(tsc)来说，这种行为会导致问题，因为：

1. tsc期望的是项目级别的类型检查，而不是单个文件
2. tsc会自动在文件路径后追加tsconfig.json查找配置
3. 项目通常有复杂的tsconfig继承关系

解决方案

方案一：使用函数式配置

lint-staged支持函数式配置，可以避免自动附加文件列表：

// lint-staged.config.js
module.exports = {
  '*.{ts,tsx}': () => [
    'tsc --noEmit',
    'yarn run prettier:fix',
    'yarn run lint:fix'
  ]
}

这种方式下，lint-staged不会自动附加文件列表，tsc会按照预期工作，使用项目根目录的tsconfig.json。

方案二：使用shell脚本包装

如果由于某些原因必须使用package.json配置，可以创建一个shell脚本来包装tsc命令：

#!/bin/sh
tsc --noEmit

然后在package.json中引用：

"lint-staged": {
  "*.{ts,tsx}": ["./scripts/typecheck.sh"]
}

最佳实践建议

1. 优先使用函数式配置：这是最简洁的解决方案，推荐在新的项目中使用

2. 考虑项目结构：对于monorepo项目，可能需要更复杂的配置来确保tsc能找到正确的配置文件

3. 结合其他工具：通常tsc类型检查会与其他工具(prettier、eslint等)一起使用，可以统一配置

4. 注意性能：全量类型检查可能较慢，对于大型项目可以考虑增量编译或其他优化手段

总结

理解lint-staged的工作机制对于正确配置至关重要。通过使用函数式配置，我们可以避免tsc命令被错误地传递文件列表参数，确保TypeScript类型检查能够正常工作。这一解决方案不仅适用于简单的项目，也能很好地支持复杂的monorepo架构。