我来自一个更熟悉的背景composer。我正在gulp（等）进行构建过程和学习node以及如何使用npm。
默认情况下不包含类似清单是非常奇怪的（同样，来自composer背景） 。composer.lock话虽如此，我一直在阅读有关 [shrinkwrap]、[npm-lockdown] 和 [npm-seal] 的文档。...而且我阅读的文档越多，我对应该选择哪种方式就越困惑（每个人都认为他们的方式是最好的方式）。我注意到的一个问题是，npm-seal在 4 年和 8 个月内没有改变npm-lockdown——这一切都让我想知道这是否是因为最新版本的npm...
PS：如果您包含每个最基本的实现示例，则布朗尼点。;)
npm shrinkwrap是锁定依赖项的最标准方法。是npm install的，默认情况下不会创建它，这很遗憾，npm 创建者肯定应该改变它。
npm-lockdown正在尝试做与 相同的事情npm shrinkwrap，有两个小点npm-lockdown更好：它更好地处理可选依赖项并验证包的校验和：
https://www.npmjs.com/package/lockdown#related-tools
这两个功能对我来说似乎都不那么重要。我很满意npm shrinkwrap：例如，npmjs 保证一旦你上传了某个版本的某个包，它就保持不变 - 所以检查 sha 校验和不是那么热（我从来没有遇到过由此引起的错误）。
seal旨在与 一起使用npm shrinkwrap。它添加了“校验和检查”方面。它看起来被遗弃而且很原始。
好问题 - 我将跳过所有内容，但shrinkwrap因为这是执行此操作的事实上的方式，根据NPM 的文档。
长话短说，该npm-shrinkwrap.json文件类似于您lock在每个其他包管理器中习惯的文件，尽管 NPM 允许同一包的不同版本通过隔离来很好地协同工作 - 实际上将不同的整个版本范围限定和复制到node_modules树的不同级别. 如果两个互为父子的项目使用完全相同的版本，NPM 将仅将版本复制到父项，子项将遍历树以查找包。
最佳实践是简单地更新package.json您的直接依赖项，运行npm install，在开发过程中验证事情是否正常，然后npm shrinkwrap在您即将提交和推送时运行。注意：确保在活动开发期间rm npm-shrinkwrap.json运行之前npm install- 如果您的直接依赖项发生了变化，那么您希望package.json使用它，而不是锁定！还包括node_modules在您的.gitignore或等效的源代码控制系统中。然后，当您部署并开始运行项目时，npm install像往常一样运行。如果 npm 找到一个npm-shrinkwrap.json文件，它将使用该文件递归地拉取所有锁定的模块，并且它将package.json在您的项目和所有依赖项目中都忽略。
您可能会发现shrinkpack很有用——它会检查 tarball，将它们npm install下载并捆绑到您的存储库中，然后最终重写 npm-shrinkwrap.json 以指向该本地包。
这样，您的项目将完全锁定，完全可以离线使用，并且安装速度更快。