我是否提交NPM 5创建的软件包锁。JSON文件？

Question

npm 5今天发布，新功能包括确定性安装，并创建了一个创建软件包 - 洛克.json文件。

该文件应该保存在源控件中吗？

我假设它类似于 <代码> Yarn.lock 和 composer.lock ，两者都应该保存在源控制中。

Answer 1

是的，软件包-Lock.json 旨在将其检查到源控件中。如果您使用的是NPM 5+，则可以在命令行上看到此通知：创建了一个lockfile作为package-lock.json。您应该提交此文件。根据 NPM帮助软件包 - 洛克 ：

package-lock.json 是为NPM的任何操作而自动生成的
修改 node_modules 树，或 package.json 。它描述了
生成的确切树，使得随后的安装能够
生成相同的树，无论中间依赖性更新如何。

此文件旨在将其投入到源存储库中，并提供服务
各种目的：

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

• 为用户提供一个设施，可以向先前的 node_modules “ Time-Travel”“ Time-Travel”，而无需提交目录本身。

• 通过可读的源控制差异促进树木变化的更大可见性。

• 并通过允许NPM跳过以前安装的软件包的重复元数据分辨率来优化安装过程。

有关 package-lock.json 的一个关键详细信息是它不能发布，并且
如果在Toplevel软件包以外的任何地方发现，将被忽略。它分享
NPM-ShrinkWrap.json的格式，本质上是同一文件，但是
允许出版。除非部署CLI工具或
否则使用出版过程来生产生产包。

如果两个 package-lock.json 和 npm-shrinkwrap.json 都存在于
包，软件包 - 洛克.json将被完全忽略。

Answer 2

是的，您应该：

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

npm CI WorkFlow 需要 存在 package> package> package-lock.json < /代码>。

---

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

• package-lock.json 和 package.json
• 如果 >缺少。

因此，运行 npm安装本地，ESP。在具有多个开发人员的大型团队中，可能会导致 package-lock.json 和开发人员决定完全删除 package> package> package> package> lock.json 。

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

从 package-lock.json 您得到的完全：已知的状态。

过去，我有没有 package-lock.json的项目一天，因为随机的依赖性有破坏性更新。

这些问题很难解决，因为您有时必须猜测最后一个工作版本是什么。

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

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

---

to 报价npm doc ：

强烈建议您将生成的软件包锁定到
来源控制：这将允许您的团队中的其他人，您的
部署，您的CI/连续集成以及其他运行的人
NPM在软件包中安装以获得完全相同的依赖关系
您正在开发的树。另外，与这些差异
更改是人类可读的，将为您告知NPM的任何更改
对您的node_modules制作，因此您可以注意到是否有任何及时
依赖项已更新，提升等

以及 npm ci vs vs vs之间的差异 NPM安装 ：

• 该项目必须具有现有的软件包 - 锁。
• 如果软件包锁中的依赖项不匹配包装中的依赖
  包锁。
• NPM CI 只能一次安装整个项目：无法使用此命令添加单个依赖项。
• 如果 node_modules 已经在 npm ci 开始安装之前自动将其删除。
• 它永远不会写入 package.json 或任何软件包锁：安装本质上是冻结的。

---

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

Answer 3

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

Answer 4

是的，最好的做法是入住（是的，入住）

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

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

Answer 5

截至2023年4月，我的答案是：

当然，您必须提交此文件，

例如，CI平台上的标准安装命令将为

npm ci

npm CI 需要该文件才能正常工作确保依赖树与所做的完全相同。

---

我的旧答案既过时了（2018年），而且缺乏知识。是：

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

1. 这是
2. gitlab-ci.yml构建的GitLab中SHA1代码完整性错误的原因。

由于我从不在pockage.json中使用 ^的

Answer 6

对于在做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 intake-lock.json（每个人都使用它），您可以将其添加到> .gitaTtributes < /code>：

package-lock.json binary
yarn.lock binary

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

Answer 7

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

package-lock.json 是为 npm 修改 node_modules tree或 package.json修改的任何操作而自动生成的。 。它描述了生成的确切树，因此随后的安装能够生成相同的树，而不论中间依赖性更新。

此文件旨在将其投入到源存储库中[。]

Answer 8

是的

，答案是肯定的，绝对总是将您的锁定命中率提交给git。

类似于Git Hashes

，如果您使用Git，则应使用锁紧file，因为它们具有相同的目的：

• A git hash 保证 files 在git存储库中的内容的稳定性。
• lockfile 保证 node_modules 内容的稳定性。

因为...

• 文件在git reto中可能会随着时间的推移而变化，但是 git hash 是指确切的文件快照。
• NPM软件包在NPM注册表中可能会随着时间的推移而变化，但是A lockfile 是指确切的依赖关系快照。

来自包装经理本身的

包装管理器供应商清楚地说，您应该提交Lockfile 。

NPM

强烈建议您将生成的软件包锁定用于源控制...

https ：//docs.npmjs.com/cli/v6/configuring-npm/package-locks

npm npm 在没有lockfile的情况下安装时，它可以清楚地告诉您lockfile：

npm notice  created a lockfile as package-lock.json. You should commit this file.

yarn

lockfiles应在所有项目上施加

“ noreferrer”> https：//classic.yarnpkg .com/blog/2016/11/24/lockfiles-for-all/

pnpm

您应该始终提交lockfile（ pnpm-lock.yaml ）。

https://pnpm.io/git

原因是

一致性

一致性应该永远相同，其构建输出应应不会随着时间的流逝而改变。

来自NPM：

[lockfile]将允许您的团队中的其他任何人，部署，CI/连续集成以及在包装源中运行NPM安装的其他任何人，以获取您正在开发的完全相同的依赖树。

来自纱线：

如果您不存储最终安装的版本，则有人可以安装相同的依赖项，最终取决于它们何时安装。这可能导致“在我的机器上起作用”问题，应避免。

更改的可追溯性

在发生变化时，您希望git跟踪这种变化。

来自NPM：

[使用lockfile] [安装]更改中的差异是可读的，并将告知您NPM对您的 node_modules > ，吊装等。

稳定性和安全性

引入错误和漏洞。

来自纱线：

由于软件包作者是人，他们可能会犯错，因此他们有可能在次要版本或补丁版中发布意外破坏变化。如果您不打算安装此破坏更改，则可能会带来不良后果，例如在生产中打破应用程序。

如果软件包作者要么是恶意的，要么被恶意的人攻击并且发布了不良版本，您不希望该代码最终运行而在不知道的情况下运行。

常见的反对意见

“没有意义”

这是“无知的论点”，这是一个逻辑上的谬论。换句话说，“我不知道原因，所以没有”。

“它是生成的”

如果此文件是自动化的，他们为什么要提交？为什么NPM不能根据我的软件包再次生成它。

响应：生成不是缺陷。产生了git犯罪。我们不应该使用git吗？事实是，lockfile不是从包装中生成的确定性，因为它容易受到 time 的影响，并且在 npm注册表中的包装状态 >。这是一个快照，以实现稳定性。

“这会导致合并冲突”，

这是解决签到的锁紧件中的合并冲突的负担。

来自NPM：

作为 [email＆nbsp; procectived] ，可以通过手动固定任何 package.json 冲突来解决这些冲突，然后运行 npm install [-package-lock--仅] 再次。




来自纱线：

当Lockfile发生合并冲突时，YARN将在运行 YARN install 时自动处理冲突解决方案。

来自PNPM：

pnpm可以自动解决 pnpm-lock.yaml 中的合并冲突。如果您有冲突，只需运行 pnpm安装并提交更改。

因此，所有软件包经理都可以自动解决锁紧冲突 。在较旧的版本中可能不是这种情况，但现在就是这种情况。

失败的唯一一次是如果 package.json 本身有冲突，因为您无法从无效的 package.json 中安装。您必须手动解决这些冲突 ，就像您必须做的那样 。

“合并冲突干扰了PR和MRS”

使用锁定文件大大增加了合并一个PR会导致第二个PR与基本分支冲突的机会。

https://docs.renovatebot.com/noise-redacter.com/noise-reduction/#lock-file - 智慧

这是真的。 GIT提供商（GitHub，GitLab等）不会自动解决Lockfile冲突，因此这可能会增加合并的负担。但是，在称重这个骗局时，请理解锁紧files通常不会改变。它们仅在 package.json deps更改时才更改，或者开发人员专门更改文件或已安装的 node_modules deps。

“它会产生差异噪声”，

如果差异工具显示锁定差异，那是很多噪音。

这是事实，但是这是一个工具问题，许多工具可以优雅地处理（例如自动最小化，分页或虚拟滚动）。如果您根本不想看到lockfile差异，请尝试 git diff-。 '：（排除）yarn.lock'，或者将文件标记为 .gitattributes 中的二进制文件（但是，如果您将看到它的差异，如果您对您很重要）。

“精确版本足够好”

为什么不仅要摆脱镜头和tildes（^ and〜）？

评论/a>

这个想法是，在 package.json 的依赖项semver表达式中不使用范围与拥有lockfile的依赖关系semver表达式相同。

这是错误的。即使您指定了确切的版本，您的依赖项也具有自己的依赖性，该依赖项可能会使用其版本范围，而不是确切的版本。因此，这最终不会锁定整个依赖树，而只能锁定其顶部。

“应用程序的Lockfiles，无库库”

的示例：

• Sindre Sorhus：“ Apps的Lockfiles，但不适合包装”” sindresorhus/ama!479
• trusktr

情感是，库需要对出血边缘deps做出反应，而没有锁定的lockfiles支持这一点。

来自纱线：

有些人想知道为什么库应该完全使用lockfiles ...开发库时使用lockfiles会创建 false安全感，因为您的用户可以安装与您不同的版本。

这在逻辑上似乎是有道理的，但是让我们更深入地研究问题。

纱线文章深入消除了这一异议。 请阅读。

此参数中的常见错误是否认为 如果您不提交锁定，则不存在 。实际上， 它仍然存在 在您的机器上，锁定了依赖关系。通过对Lockfile进行限制，这种情况无法改善。

如果图书馆维护者希望不断测试兼容性，则在安装和构建库之前，他们应该删除其锁定文件（无论是否签入Lockfile！）。与签入的锁定文件的唯一区别在于，当发生这种情况时，您会有NODE_MODULES状态的持久记录，因此将来可以再现。

为此，有 greenkeeper 的机器人。绿色管理员的倡导者在Lockfiles中检查（）和翻新bot毫无意义如果存在，请。

“锁紧files通过不同的系统产生不同的生成”，

这是提到的（例如在这里）：不同的OS会生成不同的锁定文件。如果是这种情况，这是一个错误。

但是，不同版本的 npm （或任何软件包管理器）可能会产生不同的Lockfile输出。我尚未确认这一点，但假设是这样，这是一个很小的代价来支付稳定性。为了解决此问题，贡献者将需要使用 nvm ）的工具，需要切换其包装管理器版本。

“ LockFiles可以是安全风险”

请参阅 snyk-为什么npm lockfiles可以成为注射恶意模块的安全盲点

这是一个真正的风险。一个带有Lockfile的公共项目可以接收具有Lockfile内容的恶意PR，一旦将分支拉出并安装了分支，可能会损害维护者的机器。

使用CI检查为此进行防御，例如 lockfile-lint 或简单地 npm ci 或 YARN - IMMUTABLE （ YARN - 纱线1上的frozen-lockfile ），也许设置 igaine ignore-scripts 在您的中本地 NPMRC 。

每当您安装带有不信任代码的软件包时，就会存在此风险。

总之，

总是犯下锁紧件。

Answer 9

是的，这是提交 package-lock.json 的标准练习。

进行 package-lock.json 的主要原因是项目中的每个人都在同一软件包版本上。

优点：

• 如果您遵循严格的版本操作，并且不允许自动更新到主要版本，以免自身避免在第三方套餐的向后不兼容的更改中使用包装锁，这对您有很大的帮助。
• 如果您更新特定的软件包，它将在package-lock.json中进行更新，并且使用存储库的每个人都会在吸引您的更改时更新到该特定版本。

缺点：

• 它可以使您的拉请请求看起来很丑陋:)

npm install 无法确保项目中的每个人都在同一软件包版本上。 NPM CI 将有助于解决此问题。

Answer 10

禁用包装锁。json全球

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

npm config set package-lock false

这对我来说真的很有用，就像魔术一样

Answer 11

所有反应都是肯定的；但是，根据文档，这会根据项目的类型而变化。

NPM文档部分的报价

有关 package-lock.json 的一个关键细节是不能发布，如果在Toplevel软件包以外的其他地方找到，它将被忽略。
来源：

​但是，您应该在存储库中使用 package-lock.json 来锁定测试依赖项的版本，构建依赖项等。

但是，如果您使用的是 lerna 用多个软件包管理项目，则应放置软件包-lock.json 仅在您的存储库的根部，而不是在使用 npm init 创建的每个子书中。您最终会得到这样的事情：

.git
lerna.json
package.json
package-lock.json        <--- here
packages/a/package.json
packages/a/lib/index.js
packages/b/package.json
packages/b/lib/index.js

Answer 12

tldr

在这些情况下提交：

---

1. 提交如果添加新的 npm/yarn 软件包为项目。
2. 提交如果 package.json 更新 .lock 文件中的任何更改。
3. 提交包装，nodejs或YARN中任何版本都会更新 lock 文件。

在这些情况下不承诺：

---

4. 您没有编码＆amp;您有一个更新的锁定文件

这意味着另一个开发人员在上述情况下没有推动他们的锁定文件1,2,3

6. 您刚刚拉了＆amp;您有一个更新的锁定文件

这意味着在上述情况下，另一个开发人员没有推动其锁定文件1,2,3

7. 您刚刚做了一个git clone＆amp;您有一个更新的锁定文件

这意味着在上述情况下，另一个开发人员没有按下他们的锁定文件1,2,3

8. 您编码了一个功能，并且与上述内容无关提交案例，锁定文件仍然更新了

这意味着另一个开发人员在上述情况下没有推动其锁定文件1,2,3

结论

锁定文件的主要目标就是这样
所有开发人员＆amp; 所有环境＆amp; 所有安装项目的机器应具有超准确库＆amp; 基本上，版本

仅有 3的情况。

Answer 13

是的，您应该提交它，因为它包含有关已安装的内容的信息，并且此信息可能很有用 - 例如，您可以通过执行 npm ci 在ci/cd管道中使用它。实现确定性构建或其他开发人员想要通过 npm ci 精确安装相同的依赖项。

Answer 14

关于为什么要提交软件包洛克.json

为什么不将精确版本保留在package.json？

您的软件包中。如果它们也有依赖关系（并且确实如此），那么这些版本就不会被锁定。

为什么不删除软件包洛克.json？

考虑一下，如果您删除软件包锁和重新安装，则强制依赖性树中所有包装的最新版本。意思是，您正在改变（可能）整个应用程序的行为。

您真正想做什么？
如果您有一些与NPM相关的怪异问题，只需删除node_modules并再次安装NPM。删除软件包锁。json从来都不是解决方案。

为什么要提交软件包洛克.json？
如果您不提交它，那么其他所有人都将获得的应用程序的版本与您在本地运行的版本不同。这意味着事情可能对您有用，但是破坏CI/生产/其他本地机器

希望它有助于理解。

Answer 15

我对NPM的使用是生成缩小/uglified的CSS/JS，并生成Django应用程序提供的页面中所需的JavaScript。在我的应用程序中，JavaScript在页面上运行以创建动画，有时会执行Ajax调用，在VUE框架中工作和/或与CSS一起工作。如果package-lock.json对包装中的内容具有一些压倒性的控制。根据我的经验，它要么不影响NPM安装安装的内容，要么在此过程中，它并没有对我所知的我部署的应用程序产生不利影响。我不使用传统上稀薄客户端的MongoDB或其他此类应用程序。

我从仓库中删除包装锁。
因为NPM安装生成了此文件，而NPM安装是运行应用程序的每个服务器上部署过程的一部分。节点和NPM的版本控件是在每个服务器上手动完成的，但是我要小心它们是相同的。

当在服务器上运行 npm install 时，它会更改package-lock.json，
而且，如果对服务器上的存储库记录的文件有更改，那么下一个部署将不允许您从Origin提取新更改。那是
您无法部署，因为拉力会覆盖已对包装锁的更改。

您甚至都不能覆盖本地生成的软件包 - 锁。 node_modules由于npm安装而导致，因此破坏了部署。现在，如果这表明已经在Node_Modules中安装了略有不同的版本，那再次从未引起我的问​​题。

如果node_modules不在您的存储库中（不应该是），则应忽略软件包锁。

如果我缺少某些内容，请在评论中纠正我，但是从该文件中进行版本控制的意义没有意义。文件poffage.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'

：应用NPM构建JS/CSS，如果我删除包裹锁。

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

> [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

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