GitHub Node可重用Action是否需提交node_modules？缓存与惯例咨询

哈哈，这个问题问到点子上了——我之前在维护团队内部的可重用Action时也纠结过类似的选择，结合GitHub Actions的机制和行业实践给你理清楚：

关于可重用Action的缓存问题 #

• 首先明确：用steps.uses调用的可重用Action本身是会被GitHub自动缓存的。GitHub Actions后台会把你引用的可重用工作流仓库内容（包括你已经提交的node_modules）缓存到运行器环境里，这个缓存是GitHub自动管理的，不需要你额外配置actions/cache之类的步骤。它会根据仓库的提交哈希值来判断是否需要更新缓存——只要你的可重用工作流仓库没有新的提交，每次调用都会直接用缓存好的版本，这部分确实能帮你节省重复下载的时间。
• 额外说一句：如果你想在可重用工作流内部单独缓存node_modules，其实完全没必要，因为你已经把它提交到仓库了，GitHub的自动缓存已经覆盖了这个场景，多做缓存步骤反而画蛇添足。

行业惯例：提交node_modules vs 使用vercel/ncc #

这俩方案没有绝对的对错，得看你的Action场景：

• 不推荐直接提交node_modules的情况：
  • 常规业务项目（非Action类）：node_modules体积大、包含大量平台特定文件，提交会污染版本历史，而且不同环境安装的依赖可能有差异，用npm ci或npm install更可靠。
  • 可重用Action的依赖需要频繁更新：每次更新依赖都要手动重新提交node_modules，很容易遗漏，维护成本会越来越高。
• 适合提交node_modules的情况：
  • 就像你这种轻量、依赖稳定的基础可重用工作流：只有7MB的依赖，而且长期不会变更，提交确实能大幅缩短Action的启动时间——毕竟npm install要解析依赖树、逐个下载包，哪怕是小依赖也有网络开销，直接下载缓存好的仓库内容肯定更快，这也是很多小体量公共Action的做法。
• vercel/ncc的主流适用场景：
  • 这现在是GitHub Action开发的主流方案之一：它会把你的Node.js代码和所有依赖打包成一个单独的JS文件，既避免了提交node_modules的臃肿，又能实现“零依赖启动”——运行的时候直接执行这个打包后的文件就行，不需要npm install，而且打包后的体积通常比node_modules小很多（因为只打包实际用到的代码）。
  • 适合中等以上体量、依赖有一定复杂度的Action，或者你担心node_modules带来的平台兼容性问题（比如某些依赖包含二进制文件，不同系统的版本不一样），ncc打包后的文件是跨平台的纯JS，可靠性更高。

给你的具体建议 #

• 如果你当前的方案运行稳定、依赖几乎不更新，那继续保持提交node_modules完全没问题——毕竟团队已经验证过效率更高，而且GitHub的自动缓存会帮你维持这个优势。
• 如果之后依赖需要频繁更新，或者担心node_modules的兼容性问题，那可以迁移到ncc：只需要在本地运行ncc build，把打包后的dist/index.js提交到仓库，然后在actions.yml里指定运行这个文件就行，这样既不用提交node_modules，又能保持启动速度，维护起来更省心。

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