我来自更熟悉composer的背景。我得到gulp（等）用于构建过程和学习node以及如何使用npm。
非常奇怪（再次来自composer背景）默认情况下不包含类似composer.lock的清单。话虽如此，我一直在阅读[shrinkwrap]，[npm-lockdown]和[npm-seal]的文档。 ...而且我阅读的文档越多，我就越难以选择（每个人都认为他们的方式是最好的方式）。我注意到的一个问题是npm-seal在4年内没有发生变化，8个月内npm-lockdown发生了变化 - 这一切都让我想知道这是否因为最新版本的{{{{{{ 1}} ...
PS：Brownie指出，如果你包括每个的最基本的实现示例。 ;）
答案 0 :(得分：7)
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一起使用。它增加了“校验和检查”方面。它看起来已经废弃，非常原始。
答案 1 :(得分：3)
好问题 - 我会跳过shrinkwrap以外的所有内容，因为根据NPM's docs，这是事实上的方法。
长话短说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。
答案 2 :(得分：2)
您可能会发现shrinkpack很有用 - 它会检查npm install下载的tarball并将它们捆绑到您的存储库中，最后重写npm-shrinkwrap.json以指向该本地包。
通过这种方式，您的项目完全被锁定，完全可以脱机使用，并且很多可以更快地安装。