要锁定安装在项目上的依赖项的版本，命令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？【问题讨论】：
标签： javascript node.js git npm gitignore
不，package-lock.json 不应添加到 .gitignore。相反，我强烈建议：
package-lock.json您添加到您的版本控制存储库中npm ci 而不是 npm install。ci 命令自 npm@5.7 起可用，如果有疑问，请通过以下方式升级您的 npm：npm install -g npm。）npm install 命令的最大缺点之一是它可能会改变package-lock.json 的意外行为，而npm ci 仅使用锁定文件中的版本，如果package-lock.json 和@987654336 会产生错误@ 不同步。
另外，npm ci 要求存在package-lock.json，如果不存在则会打印错误。
有一个强大的用例可以信任项目的依赖项以可靠的方式在不同机器上重复解决。
此外，npm ci 在添加依赖项之前核对整个 node_modules 文件夹，确保您使用实际依赖项而不是本地更改，同时仍然比普通的 npm install 更快。
从package-lock.json 你得到的正是：一个已知的工作状态。
在过去，我的项目没有 package-lock.json / npm-shrinkwrap.json / yarn.lock 文件，它们的构建有一天会失败，因为随机依赖项得到了破坏性更新。 （虽然很多库都遵守 semvar 版本控制指南，但您不能保证它们不会在小升级时中断。）
这些问题很难解决，因为您有时不得不猜测上一个工作版本是什么。
关于测试您项目的最新依赖项：这就是npm update 的用途，我认为它应该由开发人员运行，该开发人员也在本地运行测试，如果出现问题，由谁解决，并且然后谁提交更改的package-lock.json。 （如果升级失败，他们可以恢复到上次工作的package-lock.json。）
此外，我很少一次升级所有依赖项（因为这也可能需要进一步维护），但我宁愿挑选我需要的更新（例如 npm update {dependency} 或 npm install {dependency}@2.1.3）。这也是我将其视为手动维护步骤的另一个原因。
如果您真的想实现自动化，您可以为以下人员创建工作：
这是我会看到托管在 CI 服务器上的东西，例如Jenkins，通过将文件添加到.gitignore，不应该通过上述原因实现。
强烈建议您将生成的包锁提交到 源代码控制：这将允许您团队中的任何其他人，您的 部署，您的 CI/持续集成，以及其他任何运行的人 npm install 在您的包源中获得完全相同的依赖项 你正在开发的树。此外，与这些的差异 更改是人类可读的，并将通知您 npm 的任何更改 制作到你的 node_modules，所以你可以注意到是否有任何传递 依赖项已更新、提升等。
关于difference between npm ci vs npm install：
- 项目必须具有现有的 package-lock.json 或 npm-shrinkwrap.json。
- 如果包锁中的依赖项与 package.json 中的依赖项不匹配，
npm ci将退出并报错，而不是更新 包锁。npm ci一次只能安装整个项目：无法使用此命令添加单个依赖项。- 如果
node_modules已经存在，它将在npm ci开始安装之前自动删除。- 它永远不会写信给
package.json或任何包锁：安装基本上是冻结的。
【讨论】：
npm ci 而不是npm install。那么你的问题就会消失。
.gitignore 确实包括package-lock.json...