发布前测试 npm 包

npm 包

照片由Erol Ahmed 拍摄，来自 Unsplash

开发 npm 包时，必须确保它能够实际使用。如果测试通过、示例构建成功、演示运行正常，那当然很好，但如果用户无法安装，那就说明这个包存在问题。npm 提供了一个工具 `npm link` 来帮助用户在发布前测试包。官方文档对此有非常详细的解释，下面是一个简单的示例。你需要在包目录下运行一次，然后在应用目录下再运行一次。

~/workspace/package-name $ npm link
~/workspace/some-application $ npm link package-name

这的确是个不错的选择——如果它能正常工作的话。它npm link由来已久，可以追溯到npm@1.0很久以前，那时构建步骤还不是主流，浏览器 JavaScript 也还不是 npm 的一部分。而这些工具的普及也带来了一些问题。我遇到的主要问题有三个。

有些构建工具无法识别符号链接。

成熟的构建工具通常不会出现这个问题，或者即使出现，也能很快发现并修复符号链接的问题。然而，对于新发布的工具来说，这是一个常见问题，也是比较常见的回归错误之一。webpack针对这些问题提供了特殊的符号链接解析配置。其文档也特别提到了 npm link 可能存在的问题。

符号链接无法验证你是否已正确打包。

即使你成功运行了符号链接的包，也无法保证发布后它能正常工作。你只能确定磁盘上的所有文件都能运行。发布到 npm 的包会被打包成 tar 归档文件，并且有一些关于打包方式的配置。符号链接不会经过这些配置，因此你得到的是未经测试的配置。

模块解析无法处理两个文件树。

由于该包是一个符号链接，它存在于不同的文件树中。这导致模块解析出现一个特殊情况——一个会破坏 React 包的异常情况。当包中的组件加载 React 时，它会在文件树中查找文件夹node_modules/react，但只会找到它自己的文件夹，而不是应用程序加载的那个。这会导致加载两个不同的 React 副本，从而引发各种各样的问题。

这是最致命的问题。工具偶尔出问题尚可接受，但对于整个库类别来说，npm link这从根本上就是不兼容。这些问题让我彻底放弃了使用它们npm link。我浪费了无数个小时试图为我正在开发的软件包处理符号链接，但始终无法使其稳定运行。

现在，我使用 npm pack。

npm 包

该pack命令会创建一个 .tgz 文件，其方式与您向 npm 发布软件包时完全相同。它会从 package.json 文件中提取名称和版本信息，生成类似这样的文件package-name-0.0.0.tgz。您可以复制、上传或将此文件发送给同事。如果您发布软件包，它与上传到 npm 的文件完全一致。

~/workspace/package-name $ npm pack

文件下载完成后，就可以安装了。npm install除了 npm 之外，还可以从很多其他来源安装，我强烈建议你浏览一下文档。我们需要指定文件的完整路径，所以为了方便起见，我通常会先把它复制到我的用户目录。

~/workspace/package-name $ npm pack
~/workspace/package-name $ cp package-name-0.0.0.tgz ~
~/workspace/some-application $ npm install ~/package-name-0.0.0.tgz

你或许可以在终端里设置别名或函数来自动执行这个操作，但我用得不多，所以懒得弄。npm pack | tail -n 1这样只会把文件名输出到标准输出。（写完这段话之后，我了解到yalc有个工具可以自动完成这个操作。）

这会运行完整的发布周期——甚至包括运行publishnpm 脚本以及相关的 pre-script 和 post-script。打包并安装是模拟发布软件包的绝佳方法，而且避免了符号链接的所有怪癖和问题。

我知道，当我第一次尝试将软件包发布到 npm 时，遇到的一个难题就是弄清楚它是否真的能成功。发布的感觉就像是最终的定稿；你把它放到了全世界面前，而且那个版本号以后就再也不能用了。npm pack这让我更有信心它会按照我的预期运行。

感谢阅读！我的推特账号是@vcarl_。我管理着Reactiflux（一个面向 React 开发者的聊天室）和Nodeiflux（一个面向 Node.js 开发者的聊天室）。如果您有任何问题或建议，欢迎联系我！