Node 脚本里用 glob 时，我后来养成的路径习惯

2017年9月16日 · 阅读需 3 分钟

全栈开发者

第一次在 Node.js 脚本里用 glob，会有一种很爽的感觉：以前得自己递归目录、判断后缀，现在一条模式就能把文件找出来。可真把它用进构建脚本、批处理脚本、资源扫描脚本以后，就会发现路径这件事比模式本身更容易出问题。

我后来在项目里慢慢养成了几条习惯，不是为了写得多优雅，而是为了少掉一些跨环境的奇怪故障。

第一条：先固定基准目录，再写模式

很多出错都不是 glob 模式错了，而是脚本运行时所在目录和你想的不一样。
今天你在项目根目录跑，明天从 npm script 里跑，后天又从 CI 环境里跑，路径基准一变，结果立刻变样。

所以我后来更喜欢先明确“这段 glob 是相对于谁”的，再去写模式本身。这样脚本入口换了，文件匹配逻辑也不会跟着漂。

我以前也喜欢写那种很宽泛的模式，觉得通用。
比如一把梭去扫整个 src 或整个项目目录。后来发现这样很容易带出不该处理的文件：

与其后面再排除一堆例外，不如一开始就把目标目录写得更明确。

这是我后来特别受用的一点。
glob 只负责“找到哪些文件”，后面的业务逻辑再决定“这些文件要怎么处理”。如果两者搅在一起，后面一旦要调整匹配范围，脚本就会变得很难改。

路径匹配最好像一个干净的输入阶段，越独立越好。

那几年很多脚本只在一台机器上跑，问题还不明显；一旦项目需要在不同开发机、不同 CI 环境执行，路径分隔符和大小写差异就会冒出来。
glob 会帮你处理一部分问题，但你自己拼路径、做字符串比较时，还是得有点警惕。

所以我后来能不手写拼接就不手写，能统一交给路径工具就交给工具。

glob 这个工具本身不复杂，真正容易变复杂的是你围绕它建立的路径假设。
2017 年以后我对 Node 构建脚本最大的感觉之一，就是脚本稳定性往往不是败在功能逻辑上，而是败在“我以为路径就是这样”。把这个“以为”拿掉，脚本会稳很多。