要锁定项目上安装的依赖项版本，命令npm install会创建一个名为package-lock.json的文件。这是在Node.js v8.0.0和npm v5.0.0之后制作的，您可能知道几个人。
尽管提出了关于提交此文件的Node.js和npm建议，但是关于何时应该避免这样做的几个问题也是一种选择。通常我们会在项目中投入，但这是一个特殊的问题。
虽然默认情况下我们应该提交package-lock.json文件，但我们有一个特定的情况我们不应该这样做。例如，如果我们想测试项目依赖项的最新版本，可以选择将package-lock.json添加到.gitignore。
所以，问题如下：
package-lock.json文件添加到.gitignore？答案 0 :(得分：22)
不，package-lock.json不应添加到.gitignore。相反，我强烈建议：
您应该将package-lock.json添加到版本控制存储库中。
我还强烈建议在构建应用程序时使用npm ci而不是npm install，并且工作流存在package-lock.json。 （npm install命令的最大缺点之一是它可能会改变package-lock.json，而npm ci仅使用锁定文件中的版本并在package-lock.json和package.json时生成错误package-lock.json不同步。）
有一个强大的用例，可以相信项目的依赖关系可以在不同的机器上以可靠的方式重复解决。
从package-lock.json你得到的就是：一个已知的工作状态。
过去，我的项目没有npm-shrinkwrap.json / yarn.lock / npm update个文件，这些文件的构建会在一天内失败，因为随机依赖会导致更新。
这些问题难以解决，因为您有时不得不猜测最后一个工作版本是什么。
关于测试项目的最新依赖项：这是package-lock.json的用途，我认为它应由开发人员运行，开发人员也在本地运行测试，如果可能出现问题则解决问题，然后谁提交改变后的package-lock.json。 （如果升级失败，他们可以恢复到上一个工作.gitignore。）
此外，我很少一次升级所有依赖项（因为这也可能需要进一步维护）但我更喜欢挑选我需要的更新。这是我将其视为手动维护步骤的另一个原因。
如果您想让它自动化，您可以创建一份工作：
这是我在CI服务器上托管的内容，例如Jenkins，并且不应该通过将文件添加到npm ci来实现上述原因。
强烈建议您将生成的包锁提交到 源代码控制：这将允许您团队中的任何其他人，您的 部署，CI /持续集成以及其他任何运行的人员 npm安装在您的包源中以获得完全相同的依赖项 你正在开发的树。此外，这些差异 更改是人类可读的，并将告知您npm的任何更改 对你的node_modules做了，所以你可以注意到是否有任何传递 依赖关系已更新，悬挂等。
关于difference between npm ci vs npm install：
- 项目必须有一个现有的package-lock.json或npm-shrinkwrap.json。
- 如果包锁中的依赖项与package.json中的依赖项不匹配，
npm ci将退出并显示错误，而不是更新 包锁。node_modules一次只能安装整个项目：使用此命令无法添加单个依赖项。- 如果
npm ci已存在，则会在package.json开始安装之前自动将其删除。- 永远不会写入{{1}}或任何包锁：安装基本上都是冻结的。