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

今天发布了 npm 5 ，其中一个新特性包括创建 package-lock.json文件的确定性安装。

这个文件应该保存在源代码管理中吗？

我假设它类似于 yarn.lock和 composer.lock，它们都应该保存在源代码控制中。

884203 次浏览
小开
最佳答案

是的，package-lock.json旨在签入源代码控制。如果您使用的是npm 5+，您可能会在命令行上看到以下通知：created a lockfile as package-lock.json. You should commit this file.根据#2：

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

此文件旨在提交到源存储库中，发球各种用途：

  • 描述依赖树的单一表示形式，以保证队友、部署和持续集成安装完全相同的依赖项。

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

  • 通过可读的源代码控制差异来提高树更改的可见性。

  • 并通过允许npm跳过先前安装的包的重复元数据解析来优化安装过程。

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

如果package-lock.json和npm-shrinkwrap.json都存在于package-lock.json将被完全忽略。

小开

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

小开

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

对于npm修改node_modules或package.json树的任何操作，都会自动生成package-lock.json。它描述了生成的确切树，以便后续安装能够生成相同的树，而不管中间的依赖项更新如何。

此文件旨在提交到源存储库[.]

小开

是的，最好的做法是签到（是的，签到）

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

  1. 保证您的dev和prod环境之间的每个包的版本完全相同。这部分是在不同时间在不同环境中构建时最重要的。你可以在你的package.json中使用^1.2.3，但是你如何确保每次npm install都会在你的开发机器和构建服务器中获取相同的版本，特别是那些间接依赖包？好吧，package-lock.json将确保这一点。（在npm ci的帮助下，它基于锁文件安装包）
  2. 它改善了安装过程。
  3. 它有助于新的审计功能npm audit fix。
小开

对于在做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'"

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

package-lock.json binaryyarn.lock binary

这将导致差异显示“二进制文件a/package-lock.json和b/package-lock.json在包锁文件更改时有所不同。此外，一些Git服务（尤其是GitLab，但不是GitHub）也会在执行此操作时在线查看差异时排除这些文件（不再更改10k行！）。

小开

我不在我的项目中提交这个文件。有什么意义？

  1. 它是生成的
  2. 这是Gitlab中SHA1代码完整性错误的原因，gitlab-ci.yml构建

虽然我从来没有在package.json中使用^来表示libs，因为我有过不好的经历。

小开

全局禁用package-lock.json

在您的终端中键入以下内容：

npm config set package-lock false

这对我来说真的很神奇

小开

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

删除package-lock.json因为npm install会生成这个文件，而npm install是运行应用程序的每个服务器上部署过程的一部分。节点和npm的版本控制是在每台服务器上手动完成的，但我很小心它们是一样的。

当npm install在服务器上运行时，它会更改package-lock.json，如果服务器上的存储库记录的文件有更改，则下一个部署WONT允许您从源中提取新更改。也就是说您无法部署，因为拉取将覆盖对package-lock.json.所做的更改

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

如果node_modules不在你的repo上（也不应该），那么package-lock.json应该被忽略。

如果我遗漏了什么，请在评论中纠正我，但是从这个文件中获取版本控制是没有意义的。文件package.json中有版本号，我假设这个文件是在npm install发生时用于构建包的文件，因为当我删除它时，npm install抱怨如下：

jason@localhost:introcart_wagtail$ rm package.jsonjason@localhost:introcart_wagtail$ npm installnpm 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.jsonjason@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 ...
小开

是的，你应该：

  1. 提交package-lock.json。
  2. 使用#0而不是#1在CI和本地开发机器上构建应用程序时

npm ci工作流需要存在一个package-lock.json。

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

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

因此，在本地运行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，所以你可以注意到，如果任何传递依赖关系被更新、提升等。

关于#0与#1的区别：

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

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

小开

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

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

优点：

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

缺点：

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

npm install不会确保项目中的每个人都使用相同的包版本。npm ci将对此有所帮助。

小开

所有的答案都说“是”，但这也取决于项目，医生说：

关于package-lock.json的一个关键细节是它不能发布，如果在顶层包以外的任何地方找到它，它将被忽略。

这意味着你不需要在npm上发布你的package-lock.json依赖项，但你需要在你的repo中使用package-lock.json来锁定你的测试依赖项的版本，构建依赖项…

但是，如果您使用lerna来管理具有多个包的项目，您应该将package.json仅放在repo的根目录上，而不是在每个子包中使用npm init创建。你会得到这样的东西：

.gitlerna.jsonpackage.jsonpackage-lock.json        <--- herepackages/a/package.jsonpackages/a/lib/index.jspackages/b/package.jsonpackages/b/lib/index.js
小开

将package-lock.json提交到源代码版本控制意味着项目将使用特定版本的依赖项，这些依赖项可能与package.json.中定义的版本匹配，也可能不匹配，而依赖项具有特定版本，没有任何Caret（^）和Tilde（~），如您所见，这意味着依赖项不会更新到最新版本。

注意：如果我在CI期间将任何Caret（^）和Tilde（~）添加到要更新的依赖项中，强烈建议提交它。


提交答案