你如何处理删除 npm 包版本的人？

Question

今天我发现我的应用程序依赖的一个 npm 包版本 Babel 6.0.15 已从 npm 中删除。

这导致在新电脑上编译失败，我不得不手动为它找到最接近的可用版本，并且所有级联版本都会更改它影响相关软件包。

既然我知道它们随时可能丢失，那么处理 npm 包的最佳方法是什么？

• 您是否将 node_modules 文件夹检查到源代码管理中？
• npm 是否有关于创建者可以删除哪些版本（主要、次要等）以及哪些更“长期支持”且必须保留的规则？
• 当新电脑上的“npm update”失败时，如何让 npm 在本地通知你，而不是静默失败？

Answer 1

在考虑了一段时间后，我写了一个blog post 总结了我认为的最佳实践。转载如下：

总结

• 指定所有 npm 模块的确切版本，例如“alt”：“0.17.8”
• 将您的 node_modules 文件夹提交到源代码管理中
• 不要使用DefinitelyTyped 或任何其他外部库Typescript 定义工具

为什么？

其中一些原则可能会引起争议，所以这是我的推理：

指定所有 npm 模块的确切版本

Semver（语义版本控制）表示只有在主要版本发生变化时才会发生重大变化。所以你应该可以只说“alt”：“0.17”

但我在实践中发现，即使是补丁更改（错误修复）也会破坏您的应用程序——因为依赖这些库的库通常希望特定版本中的一些微小行为不会改变。因此，为了使特定库的所有特定版本都能正常工作，它们需要依赖其他库的确切版本。

将您的 node_modules 文件夹提交到源代码管理中

我首先假设著名的 npm 库的所有版本都将无限期地保留在那里。但后来我发现创建者经常从 npm 中删除他们软件的旧版本——这会破坏您为应用程序配置的确切版本号依赖项的级联链。

是的，提交所有 npm 库会占用存储库中的空间，但它们毕竟是文本文件，而不是 .DLL，因此它们会被压缩得非常小。另一种选择是有一天无法在新计算机上编译您的应用程序，因为库已从 npm 中完全删除。

不要使用 DefinedTyped 或任何其他外部库 Typescript 定义工具

如果您使用的外部工具出现编译错误，那真是太好了。但我发现这样做不值得，因为：

• 无法匹配定义文件版本号和 npm 库版本号，因此您得到的定义与您正在使用的库不同步
• 他们经常有错误
• 您在编译时捕获的类型错误可能会发生在您自己的应用程序中，而不是您调用外部库的方式中

不要将 .d.ts 文件用于外部库，只需说：

declare module 'lodash'
{
    let x: any;
    export = x;
}

或者在 Typescript 1.8 以后使用 –allowJS 标志。