EP222. “清理 package.json 与 npm-run-all 合并构建命令”

这一章的收尾整理：① 反复复制粘贴 Block 文件夹的过程中，build/ 目录积累了不少没用的垃圾文件夹（比如 archive copy）——解法很直接，直接删掉整个 build/ 文件夹重新生成，因为这个目录本来就应该「随时可以从源代码重新生成，不用手动清理」；② 整理 package.json 的脚本：新增一个一次性的 build 命令（内部依次跑 buildindex 和 buildblocks 两个子任务），用官方的 npm-run-all 包实现「按顺序而不是同时」执行；③ 精简 start 脚本，不再需要手动罗列每一个 Block 的入口路径。这标志着整个 Block Theme 已经 100% 采用官方标准工具链。

涉及文件

• wp-content/themes/fictional-clean-blocks/build/ （整个删除，重新生成）
• wp-content/themes/fictional-clean-blocks/package.json （修改）

代码实现

先删除整个 build/ 目录（它应该始终是可以从源码重新生成的构建产物，不需要手动清理里面的垃圾文件夹）

安装 npm-run-all 包：

npm install npm-run-all

package.json：新增 build/buildindex/buildblocks 三个脚本，精简 start 脚本：

{
  "scripts": {
    "start": "wp-scripts start src/index.js",
    "build": "run-s buildindex buildblocks",
    "buildindex": "wp-scripts build src/index.js",
    "buildblocks": "wp-scripts build --experimental-modules",
    "blocks": "wp-scripts start --experimental-modules",
    "test": "echo \"Error: no test specified\" && exit 1"
  }
}

关键改动点：

• build/ 目录的正确心态：随时可以删、随时能重新生成——不应该手动去里面清理某个多余的子文件夹，直接整个删掉、重新跑一次构建命令,永远比手动排查垃圾文件更省心也更可靠
• npm-run-all 这个第三方 npm 包：提供 run-s（sequential，按顺序执行）和 run-p（parallel，同时并行执行）两个命令行工具——这一讲用的是 run-s，因为「先处理 src/index.js 这类非 Block 资源、再处理所有 Block」有明确的先后关系，不需要（也不应该）同时跑
• build 命令的实际内容：run-s buildindex buildblocks——先完整跑完 buildindex 这个任务，再开始跑 buildblocks，保证两次构建不会互相冲突干扰
• buildindex：wp-scripts build src/index.js——只负责处理 src/index.js 这个入口（非 Block 相关的主题 JS/CSS，比如首页幻灯片脚本、全局样式等）
• buildblocks：wp-scripts build --experimental-modules——不传任何具体入口文件路径，让它按默认行为自动扫描 src/ 下所有带 block.json 的子文件夹，一次性构建所有已迁移的 Block
• start 脚本大幅精简：从原本需要手动列出 our-blocks/banner.js our-blocks/genericheading.js ... 这一长串路径,精简成只有 wp-scripts start src/index.js——因为不再有任何 Block 使用旧的手写路径体系,start 现在只需要负责非 Block 的主题资源
• blocks 脚本保持独立（wp-scripts start --experimental-modules）：跟 start 分开、在另一个终端窗口单独运行,专门负责「开发过程中持续监听 Block 源码变化并自动重新编译」
• 作者明确说明「一次性构建」和「持续监听开发」是两条不同的路：build（一次性构建全部内容，适合发布/部署前用）已经能一条命令搞定；但如果想要「开发过程中保存文件就自动重新编译」这种持续监听体验，start 和 blocks 依然需要分别在两个终端窗口里跑——作者提到自己试过至少 5 种第三方方案/策略，都没能可靠地把这两个「监听任务」合并成一条命令同时跑，索性放弃合并、直接用两个终端窗口
• 对手动折腾 Webpack 配置的态度：作者明确建议「能不碰 Webpack 配置就尽量不要碰」——虽然理论上可以深入配置层面把两个监听任务合并，但从长期维护和踩坑成本考虑，维持两个独立终端窗口是更务实的选择,不需要为了「表面上更优雅」牺牲长期可维护性

Hook / Function 速查

常见坑

• 手动去 build/ 目录里排查、删除某几个垃圾子文件夹——这个目录本来就该是「构建产物」，直接整个删掉重新生成更可靠，没必要手动清理
• 把 run-s（顺序执行）错用成 run-p（并行执行）去构建 index.js 和所有 Block——两个构建任务之间如果本身有依赖或者共享的中间状态，并行执行可能出现时序问题
• 试图把「持续监听开发」的 start 和 blocks 两个任务合并成一条命令——作者提到试过多种第三方方案都不可靠，与其钻研 Webpack 配置，不如务实地用两个独立终端窗口

延伸 / 后续讲座会用到

这一讲是 Block Theme 现代化改造章节的收尾。下一章（Interactivity API）会介绍如何让 Block 前台脚本用官方标准方式访问 Block 实例数据,不再需要手工搭建 PHP-HTML-JS 之间的传递桥梁。

Sources

Udemy：

• Become a WordPress Developer: Unlocking Power With Code — Section 29, EP222