是的，提交package-lock.json是一种标准做法。

提交package-lock.json的主要原因是项目中的每个人都使用相同的包版本。

赞成的意见：

如果您遵循严格的版本控制，并且不允许自动更新到主要版本，以避免在第三方包中发生向后不兼容的更改，那么提交包锁定会有很大帮助。如果您更新了一个特定的包，它会在package-lock.json中更新，并且使用存储库的每个人在接受您的更改时都会更新到该特定版本。

欺骗：

这会让你的拉取请求看起来很难看：）

npm安装无法确保项目中的每个人都使用相同的软件包版本。npm ci将对此有所帮助。

将package-lock.json提交到源代码版本控制意味着项目将使用特定版本的依赖项，该依赖项可能与package.json中定义的依赖项相匹配，也可能与之不匹配。虽然依赖项具有特定版本，但如您所见，没有任何Caret（^）和Tilde（~），这意味着依赖项不会更新到最新版本。npm install将获取当前版本Angular所需的相同版本。

注意：package-lock.json强烈建议在CI期间将任何Caret（^）和Tilde（~）添加到要更新的依赖项时提交它。

我对npm的使用是生成缩小/放大的css/js，并生成django应用程序提供的页面所需的javascript。在我的应用程序中，Javascript在页面上运行以创建动画，有时执行ajax调用，在VUE框架内工作和/或使用css。如果package-lock.json对package.json中的内容有一些重写控制，那么可能需要有一个版本的该文件。根据我的经验，它要么不会影响npm install所安装的内容，要么会影响，到目前为止，据我所知，它还没有对我部署的应用程序产生不利影响。我不使用mongodb或其他传统的瘦客户端应用程序。

我从repo中删除package-lock.json因为npm安装会生成此文件，而npm安装是运行应用程序的每台服务器上部署过程的一部分。node和npm的版本控制是在每台服务器上手动完成的，但我要注意它们是相同的。

当npm安装在服务器上运行时，它会更改package-lock.json，如果服务器上的repo记录了文件的更改，则下一个部署WONT允许您从源位置提取新的更改。那就是无法部署，因为拉操作将覆盖对package-lock.json所做的更改。

您甚至不能用repo（重置硬源主机）上的内容覆盖本地生成的package-lock.json，因为如果package-llock.json由于npm安装而无法反映node_modules中的内容，从而破坏部署，那么当您发出命令时，npm会发出抱怨。现在，如果这表明node_modules中安装了稍微不同的版本，那么这再次不会给我带来问题。

如果node_modules不在您的repo中（而且不应该在），那么package-lock.json应该被忽略。

如果我遗漏了什么，请在评论中纠正我，但版本控制是从这个文件中提取的这一点毫无意义。package.json文件中有版本号，我假设这个文件是在npm安装发生时用来构建包的文件，当我删除它时，npm安装会如下所示：

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

但是，当安装node_modules或将npm应用于构建js/css时，如果删除package-lock.json，则不会产生任何抱怨

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

是的，您应该：

提交package-lock.json。在ci和本地开发计算机上构建应用程序时，请使用npm-ci而不是npm-install

npm-ci工作流要求存在package-lock.json。

npm install命令的一个大缺点是它的意外行为，即它可能会改变package-lock.json，而npm ci只使用锁定文件中指定的版本并产生错误

如果package-lock.json和package.json不同步如果缺少package-lock.json。

因此，在本地运行npm安装，特别是在具有多个开发人员的大型团队中，可能会导致package-lock.json内部发生大量冲突，开发人员决定完全删除package-llock.json。

然而，有一个强大的用例可以证明，项目的依赖关系可以在不同的机器上以可靠的方式重复解决。

从package-lock.json中，您可以得到确切的结果：已知工作状态。

过去，我有一些没有package-lock.json/npm-shrinkwrap.json/yarn.lock文件的项目，它们的构建有一天会失败，因为一个随机依赖项得到了破坏性的更新。

这些问题很难解决，因为您有时不得不猜测上一个工作版本是什么。

如果要添加新的依赖项，仍然可以运行npm install｛dependency｝。如果要升级，请使用npm update｛dependency｝或npm install$｛dependency｝@｛version｝并提交更改的package-lock.json。

如果升级失败，您可以恢复到最后一个已知的工作包-lock.json。

引用npm文档：

强烈建议您将生成的包锁提交到源代码管理：这将允许团队中的任何其他人部署、您的CI/持续集成以及任何其他运行在包源中安装npm，以获得完全相同的依赖关系此外更改是人类可读的，并将通知您npm的任何更改设置为node_modules，因此您可以注意到依赖关系得到更新、提升等。

关于npm ci与npm install之间的区别：

项目必须具有现有的package-lock.json或npm-shrinkwrap.json。如果包锁中的依赖项与package.json中的依赖不匹配，npm-ci将退出并返回错误，而不是更新包裹锁。npmci一次只能安装整个项目：不能使用此命令添加单个依赖项。如果node_modules已经存在，则在npm-ci开始安装之前，它将被自动删除。它永远不会写入package.json或任何包锁：安装基本上是冻结的。

注：我在这里发布了类似的答案

是的，它打算被签入。我想建议它获得自己独特的提交。我们发现它给我们的差异增加了很多噪音。

全局禁用package-lock.json

在终端中键入以下内容：

npm config set package-lock false

这对我来说真的很管用