是否应该将package-lock.json文件添加到.gitignore？
要锁定项目上安装的依赖项的版本，该命令将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。相反，我强烈建议：
- 在本地和部署管道中构建应用程序时， 。
（该
ci命令自npm@5.7起可用，如有疑问，请通过以下方式升级npm ：）npm install -g npm。
该npm install命令最大的缺点之一是它的意外行为，它可能会使突变package-lock.json，而npm
ci仅在锁文件中使用该版本，如果package-lock.json和package.json不同步，则会产生错误。
另外，npm ci要求 存在a package-lock.json，如果不存在则会打印错误。有一个强大的用例，可以信任该项目的依赖项可以在不同机器上以可靠的方式重复解决。
此外，在添加依赖项之前先npmci对整个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 doc：
强烈建议您将生成的程序包锁定提交给源代码控制：这将允许您团队中的其他任何人，您的部署，您的CI
/持续集成以及在包源中运行npm的其他任何人都可以在程序包源中获得完全相同的依赖关系树你在继续发展。此外，这些更改的差异是人类可读的，并且会通知您npm对您的node_modules所做的任何更改，因此您可以注意到是否有任何传递性依赖项被更新，提升等。
并且关于vs 之间npm ci``npm
install的区别：
- 该项目必须具有现有的package-lock.json或npm-shrinkwrap.json。
- 如果包锁中的依赖项与package.json中的依赖项不匹配，
npm ci则将退出并显示错误，而不是更新包锁。npm ci一次只能安装整个项目：不能使用此命令添加单个依赖项。- 如果
node_modules已经存在，它将在npm ci开始安装之前被自动删除。- 它永远不会写入
package.json或执行任何程序包锁定：安装实际上是冻结的。
以上是 是否应该将package-lock.json文件添加到.gitignore？ 的全部内容， 来源链接： utcz.com/qa/436113.html
