是否提交由npm 5创建的package-lock.json文件？

全局禁用package-lock.json

在终端中输入以下内容：

npm config set package-lock false

这真的像魔术一样对我有用

是的，您可以提交此文件。来自npm的官方文档：

package-lock.json会为npm修改node_modules树或的任何操作自动生成package.json。它描述了生成的确切树，因此无论中间依赖项更新如何，后续安装都可以生成相同的树。

该文件旨在提交到源存储库中。

我不在项目中提交此文件。重点是什么 ？

1. 它产生了
2. 这是使用gitlab-ci.yml构建的gitlab中SHA1代码完整性错误的原因

尽管的确我从来没有在package.json的lib中使用^，因为我对此有不好的经验。

是的你应该：

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

该npm ci工作流程需要的存在package-lock.json。

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

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

因此，在npm install本地运行，尤其是。在具有多个开发人员的大型团队中，可能会导致内的许多冲突，package-lock.json而开发人员决定完全删除该冲突package-lock.json。

但是，有一个强大的用例可以信任项目的依赖项在不同机器上以可靠的方式重复解决。

从中package-lock.json您可以确切地得到：一个已知的工作状态。

过去，我有没有package-lock.json/ npm-shrinkwrap.json/ yarn.lock文件的项目，由于随机依赖项的最新更新，其构建将有一天失败。

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

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

如果升级失败，则可以恢复到上一个​​已知的工作状态package-lock.json。

要引用文档NPM：

It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on. Additionally, the diffs from these changes are human-readable and will inform you of any changes npm has made to your node_modules, so you can notice if any transitive dependencies were updated, hoisted, etc.

And in regards to the difference between npm ci vs npm install:

• The project must have an existing package-lock.json or npm-shrinkwrap.json.
• If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
• npm ci 一次只能安装整个项目：不能使用此命令添加单个依赖项。
• 如果node_modules已经存在，它将在npm ci开始安装之前自动删除。
• 它将永远不会写入package.json或执行任何软件包锁：安装实际上是冻结的。

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

是的，最佳做法是办理登机手续（是，请办理登机手续）

我同意在看到差异时会引起很多噪音或冲突。但是好处是：

1. 保证每个软件包的版本完全相同。在不同时间，不同环境中构建时，此部分最重要。您可以^1.2.3在中使用package.json，但是您如何确保每次npm install都能在开发机和构建服务器中使用相同的版本，尤其是那些间接依赖包？好吧，package-lock.json将确保这一点。（借助npm ci它可以基于锁定文件安装软件包）
2. 它改善了安装过程。
3. 它有助于新的审核功能npm audit fix（我认为审核功能来自npm版本6）。

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

是的，package-lock.json旨在被检查到源代码管理中。如果您使用的是npm 5，则可能会在命令行上看到：created a lockfile as package-lock.json. You should commit this file.根据npm help package-lock.json：

package-lock.json会为npm修改node_modules树或的任何操作自动生成package.json。它描述了生成的确切树，因此无论中间依赖项更新如何，后续安装都可以生成相同的树。

该文件旨在提交到源存储库中，并具有多种用途：

• 描述一个依赖关系树的单一表示，这样可以确保队友，部署和持续集成安装完全相同的依赖关系。

• 为用户提供一种工具，使其可以“时间旅行”到以前的状态，node_modules而不必提交目录本身。

• 为了通过可读的源代码控制差异更好地了解树的变化。

• 并允许npm跳过以前安装的软件包的重复元数据解析，从而优化安装过程。

关于package-lock.json它的一个关键细节是它无法发布，并且如果在顶级软件包之外的任何地方找到它，它将被忽略。它与npm-shrinkwrap.json（5）共享一种格式，该格式本质上是相同的文件，但允许发布。除非部署CLI工具或使用发布过程来生产生产软件包，否则不建议这样做。

如果软件包的根目录中同时存在package-lock.json和npm-shrinkwrap.json，package-lock.json将被完全忽略。