npm scripts的高级玩法：pre、post和--，你真的会用吗？

我们每天的开发，可能都是从一个npm run dev开始的。npm scripts对我们来说，天天用它，但很少去思考它。

不信，你看看你项目里的package.json，是不是长这样👇：

"scripts": {
  "dev": "vite",
  "build": "rm -rf dist && tsc && vite build", // 嘿，眼熟吗？
  "lint": "eslint .",
  "lint:fix": "eslint . --fix",
  "test": "vitest",
  "test:watch": "vitest --watch",
  "preview": "vite preview"
}

这能用吗？当然能用。

但这专业吗？在我看来，未必！

一个好的scripts，应该是原子化的、跨平台的 。而上面这个，一个build命令就不行，而且rm -rf在Windows上还得装特定环境才能跑🤷‍♂️。

今天，我就来聊聊，如何用pre、post和--，把你的脚本，升级成专业的脚本。

---

pre 和 post：命令的生命周期钩子

pre和post，是npm内置的一种钩子机制。

它的规则很简单：

• 当你执行npm run xyz时，npm会自动 先去找，有没有一个叫prexyz的脚本，有就先执行它。
• 当xyz执行成功后，npm会自动 再去找，有没有一个叫postxyz的脚本，有就最后再执行它。

这个自动的特性，就是神一般的存在。

我们来改造那个前面👆提到的build脚本。

业余写法 (用&&手动编排)

"scripts": {
  "clean": "rimraf dist", // rimraf 解决跨平台删除问题
  "lint": "eslint .",
  "build:tsc": "tsc",
  "build:vite": "vite build",
  "build": "npm run clean && npm run lint && npm run build:tsc && npm run build:vite"
}

你的build脚本，它必须记住所有的前置步骤。如果哪天你想在build前，再加一个test，你还得去修改build的定义。这违反了单一职责。

专业写法 (用pre自动触发)

"scripts": {
  "clean": "rimraf dist",
  "lint": "eslint .",
  "test": "vitest run",
  "build:tsc": "tsc",
  "build:vite": "vite build",

  // build的前置钩子
  "prebuild": "npm run clean && npm run lint && npm run test", 
  
  // build的核心命令
  "build": "npm run build:tsc && npm run build:vite",
  
  // build的后置钩子
  "postbuild": "echo 'Build complete! Check /dist folder.'"
}

看到区别了吗？

现在，当我只想构建时，我依然执行npm run build。

npm会自动帮我执行prebuild（清理、Lint、测试）👉 然后执行build（编译、打包）👉 最后执行postbuild（打印日志）。

我的build脚本，只关心构建这件事 。而prebuild脚本，只关心前置检查这件事。

这就是单一职责和关注点分离。

你甚至可以利用这个特性，搞点骚操作😁：

"scripts": {
  // 当你执行npm start时，它会自动先执行npm run build
  "prestart": "npm run build", 
  "start": "node dist/server.js"
}

---

-- (双短线)：脚本参数

--是我最爱的一个特性。它是一个参数分隔符。

它的作用是：告诉npm，我的npm参数到此为止了，后面所有的东西，都原封不动地，传给我要执行的那个底层命令。"

我们来看开头👆那个脚本：

"scripts": {
  "test": "vitest",
  "test:watch": "vitest --watch"
}

为了一个--watch参数，你复制了一个几乎一模一样的脚本。如果明天你还想要--coverage呢？再加一个test:coverage？这叫垃圾代码💩。

专业写法 (用--动态传参)

"scripts": {
  "test": "vitest"
}

就这一行，够了。

等等，那我怎么跑watch和coverage？

答案，就是用--🤷‍♂️：

# 1. 只跑一次
$ npm run test -- --run
# 实际执行: vitest --run

# 2. 跑watch模式
$ npm run test -- --watch
# 实际执行: vitest --watch

# 3. 跑覆盖率
$ npm run test -- --coverage
# 实际执行: vitest --coverage

# 4. 跑某个特定文件
$ npm run test -- src/my-component.test.ts
# 实际执行: vitest src/my-component.test.ts

--就像一个参数隧道 ，它把你在命令行里，跟在--后面的所有参数，原封不动地扔给了vitest命令。

---

一个专业的CI/CD脚本

好了，我们把pre/post和--结合起来，看看一个专业的package.json是长什么样子👇。

"scripts": {
  // 1. Lint
  "lint": "eslint .",
  "lint:fix": "eslint . --fix",

  // 2. Test
  "test": "vitest",
  "pretest": "npm run lint", // 在test前，必须先lint

  // 3. Build
  "build": "tsc && vite build",
  "prebuild": "npm run test -- --run", // 在build前，必须先test通过
  
  // 4. Publish (发布的前置钩子)
  // prepublishOnly 是一个npm内置的、比prepublish更安全的钩子
  // 它只在 npm publish 时执行，而在 npm install 时不执行
  "prepublishOnly": "npm run build" // 在发布前，必须先build
}

看看我们构建了怎样一条自动化脚本：

1. 你兴高采烈地敲下npm publish，准备发布。
2. npm一看，有个prepublishOnly，于是它先去执行npm run build。
3. npm一看，build有个prebuild，于是它又先去执行npm run test -- --run。
4. npm一看，test有个pretest，于是它又双叒叕先去执行npm run lint。

最终的执行流是：Lint -> Test -> Build -> Publish。

这些脚本，被pre钩子，自动地、强制地串联了起来。你作为开发者，根本没有机会犯错。你不可能发布一个连Lint都没过或者测试未通过的包😁。

---

npm scripts，它不是一个简单的脚本快捷方式。它是一个工作流（Workflow）的定义 。

pre和post，定义了你工作流的执行顺序 和依赖 ，保证了代码检查 等功能，而--是确保你工作流中的脚本参数。

现在，马上去打开你项目的package.json，看看它，是专业的，还是业余的呢？🤣