要锁定在项目上安装的依赖项的版本，命令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？ - 是否有任何我们必须或不能这样做的特殊情况？
不，不应将package-lock.json添加到.gitignore中。相反，我强烈建议：
-
将
package-lock.json添加到版本控制存储库 - 在本地和部署管道中构建应用程序时，请使用
npm ci而不是npm install.
(ci命令从 npm@5.7 开始可用，如果有疑问，请通过以下方式升级 npmnpm install -g npm.)
npm install命令的最大缺点之一是它可能会改变package-lock.json的意外行为，而npm ci只使用锁文件中的版本，如果package-lock.json和package.json不同步，则会产生错误。
此外，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)。这也是为什么我会将其视为手动维护步骤的另一个原因。
如果你真的想让它自动化，你可以为以下人员创建一个工作：
- 结帐存储库
- 运行 npm 更新
- 运行测试
- 如果测试通过，则提交并推送到存储库
- 否则失败并报告要手动解决的问题
这是我会看到托管在 CI 服务器上的东西，例如Jenkins，它不应该通过上述原因通过将文件添加到.gitignore来实现。
或者引用 npm 文档：
强烈建议您将生成的包锁提交到 源代码控制：这将允许团队中的其他任何人，您的 部署、CI/持续集成以及运行的任何其他人 在包源中安装 npm 以获得完全相同的依赖项 你正在开发的树。此外，与这些的区别 更改是人类可读的，并且会通知您 npm 的任何更改 制作到您的node_modules，因此您可以注意到是否有任何传递 依赖项已更新、提升等。
关于npm ci与npm install之间的区别：
- 该项目必须具有现有的 package-lock.json 或 npm-shrinkwrap.json。
- 如果包锁中的依赖项与 package.json 中的依赖项不匹配，
npm ci将退出并显示错误，而不是更新 包锁。npm ci一次只能安装整个项目：不能使用此命令添加单个依赖项。- 如果
node_modules已存在，则会在npm ci开始安装之前自动将其删除。- 它永远不会写入
package.json或任何包锁：安装基本上被冻结。