使用husky+lint-staged能否在pre-commit阶段校验暂存代码可正常构建？

你遇到的报错和lint-staged的执行逻辑直接相关，但并非是「仅针对暂存文件执行构建」导致的，核心问题是：

lint-staged默认会将所有匹配到的暂存文件路径作为参数，传递给任务数组中定义的每一条命令。

你将yarn build写在lint-staged的任务数组中，实际执行的命令为yarn build 暂存文件1路径 暂存文件2路径 ...，大部分前端框架的build命令（如Next.js、Umi等）会将额外的位置参数识别为自定义构建目标目录，替换掉默认的项目根目录下的源码目录，自然就会出现找不到pages等预设目录的报错。

你的需求完全可以实现，根据项目情况可以选择以下两种配置方案：

方案1：直接在pre-commit钩子中执行构建（推荐，和CI逻辑完全对齐） #

直接修改.husky/pre-commit钩子文件，内容参考如下：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# 先执行暂存文件的格式化、lint校验
npx lint-staged
# 校验通过后执行全量构建，构建失败则阻止提交
yarn build

同时修改你的lint-staged配置，移除其中的yarn build命令：

"lint-staged": {
    "**/*.{js,jsx,ts,tsx,css,md}": [
      "prettier --write"
    ]
  }

该方案逻辑简单无额外兼容问题，唯一缺点是项目体积较大时，全量构建会拉长提交耗时。

方案2：在lint-staged中执行构建（不推荐） #

如果你确实要把构建命令放在lint-staged中，可以在命令后加--占位符，告诉lint-staged不要传递暂存文件参数：

"lint-staged": {
    "**/*.{js,jsx,ts,tsx,css,md}": [
      "prettier --write",
      "yarn build --"
    ]
  }

该方案效果和方案1一致，但多了一层无意义的文件匹配判断，执行效率略低于方案1。

优化建议 #

如果觉得全量构建耗时过长，可以在pre-commit阶段先执行tsc --noEmit做类型校验、eslint做代码规范校验，再搭配框架的增量构建参数（如Vite的--incremental）做增量构建校验，在耗时和准确性之间做平衡。

内容的提问来源于stack exchange，提问作者user1259167