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

npm 5今天发布，其中一项新功能包括确定性安装以及package-lock.json文件的创建。

该文件应该保留在源代码管理中吗？

我假设它类似于yarn.lock和composer.lock，这两个都应该保留在源代码管理中。

是的，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将被完全忽略。

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

是的你应该：

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：

强烈建议您将生成的程序包锁定提交给源代码管理：这将允许您团队中的其他任何人，您的部署，您的CI /持续集成以及在包源中运行npm的其他任何人都可以在程序包源中获得完全相同的依赖关系树你在继续发展。此外，这些更改的差异是人类可读的，并且会通知您npm对您的node_modules所做的任何更改，因此您可以注意到是否有任何传递性依赖项被更新，提升等。

并且关于vs 之间npm cinpm install的区别：

• 该项目必须具有现有的package-lock.json或npm-shrinkwrap.json。
• 如果包锁中的依赖项与package.json中的依赖项不匹配， npm ci则将退出并显示错误，而不是更新包锁。
• 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）。

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

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

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

对于抱怨git diff时产生噪音的人们：

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

我所做的是使用别名：

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

要忽略整个存储库（每个使用它的人）在diffs中的package-lock.json，可以将其添加到.gitattributes：

package-lock.json binary
yarn.lock binary

这将导致差异显示“每当更改包锁定文件时二进制文件a / package-lock.json和b / package-lock.json都不同。此外，某些Git服务（尤其是GitLab，但不是GitHub）也将排除在外在网上查看时，这些文件（不再更改10k行！）来自差异文件。

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

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

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

全局禁用package-lock.json

在终端中输入以下内容：

npm config set package-lock false

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

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

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

优点：

• 如果您遵循严格的版本控制，并且不允许自动更新到主要版本，则可以避免第三方软件包的向后不兼容更改，从而使软件包锁定很有帮助。
• 如果您更新了某个特定的程序包，则它会在package-lock.json中进行更新，并且使用存储库的每个人都会在获取所做更改后更新到该特定版本。

缺点：-

• 它会使您的请求请求看起来很丑陋:)'

编辑：-npm install不能确保项目中的每个人都使用相同的软件包版本。npm ci将对此提供帮助。

我使用npm的目的是生成缩小/缩小的css / js并生成django应用程序服务的页面中所需的javascript。在我的应用程序中，Javascript在页面上运行以创建动画，有时执行ajax调用，在VUE框架内工作和/或与CSS一起工作。如果package-lock.json对package.json中的内容具有某种压倒性的控制权，那么可能需要此文件有一个版本。以我的经验，它要么不会影响npm install所安装的内容，要么会影响到目前为止我所学的应用程序。我不使用mongodb或传统上是瘦客户端的其他此类应用程序。

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

在npm install服务器上运行时，它将更改package-lock.json，并且如果服务器上的存储库记录了对文件的更改，则下一次部署WONT允许您从源中提取新更改。那是您无法部署，因为请求将覆盖对package-lock.json所做的更改。

您甚至无法用存储库（重置硬原始主机）上的内容覆盖本地生成的package-lock.json，因为如果package-lock.json无法反映其中的内容，那么在您发出命令时npm都会抱怨由于npm install而导致node_modules中断，因此中断了部署。现在，如果这表明在node_modules中已安装了稍有不同的版本，则再也不会导致我出现问题。

如果node_modules不在您的存储库中（也不应该在存储库中），则应忽略package-lock.json。

如果我丢失了某些内容，请在评论中更正我，但是从该文件中获取版本控制这一点毫无意义。文件package.json中具有版本号，并且我假设此文件是在npm install发生时用于构建软件包的文件，因为当我删除它时，npm install抱怨如下：

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 ...