rin*_*t.6 1164 git version-control lockfile node.js npm
npm 5今天发布,其中一项新功能包括创建package-lock.json文件的确定性安装.
这个文件应该保存在源代码管理中吗？
我假设它类似于,yarn.lock并且composer.lock两者都应该保留在源代码控制中.
vin*_*e77 1380
是的,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将被完全忽略.
xer*_*r0x 100
是的,它打算被签入.我想建议它获得自己独特的提交.我们发现它给我们的差异增加了很多噪音.
Xin*_*Xin 50
是的,最佳做法是办理登机手续
我同意在看到差异时会引起很多噪音或冲突.但好处是:
^1.2.3你的package.json,但你怎么能保证每次都npm install将搭载相同的版本在你的dev的机器和构建服务器,尤其是那些依赖间接包？好吧,package-lock.json将确保.(借助于npm ci安装基于锁文件的包)npm audit fix(我认为审计功能来自npm版本6).Deu*_*unz 33
我不在我的项目中提交此文件.重点是什么 ？
虽然我从来没有在我的package.json中使用^用于libs,因为我对它有糟糕的经历:)
问候.
Raz*_*aza 29
在做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'"
k0p*_*kus 28
是的你应该：
package-lock.json。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或执行任何软件包锁：安装实际上是冻结的。
注意：我在这里发布了类似的答案
Mat*_*ley 20
答案是肯定的，绝对总是将你的锁文件提交到 git。
\n如果您使用 git，则应该使用锁定文件，因为它们具有相同的目的：
\n因为...
\n包管理器供应商明确表示您应该提交锁定文件。
\n\n\n强烈建议您将生成的包锁提交到源代码管理...
\n
https://docs.npmjs.com/cli/v6/configuring-npm/package-locks
\n什么时候npm没有锁定文件安装时，它会清楚地告诉您提交锁定文件：
npm notice created a lockfile as package-lock.json. You should commit this file.\n\n\n应在所有项目上提交锁定文件
\n
https://classic.yarnpkg.com/blog/2016/11/24/lockfiles-for-all/
\n\n\n\n您应该始终提交锁文件 (
\npnpm-lock.yaml)。
单个提交应该永远相同，并且其构建输出不应随着时间的推移而改变。
\n来自 npm：
\n\n\n[锁定文件] 将允许您的团队中的其他人、您的部署、CI/持续集成以及在包源中运行 npm install 的任何其他人获得与您正在开发的完全相同的依赖关系树。
\n
从纱线：
\n\n\n如果您不\xe2\x80\x99t 存储最终安装的版本，则某人可能会安装同一组依赖项，并根据安装时间而最终获得不同的版本。这可能会导致 \xe2\x80\x9cWorks On My Machine\xe2\x80\x9d 问题，应该避免。
\n
当某些事情发生变化时，您希望 git 跟踪该变化。
\n来自 npm：
\n\n\n[使用锁定文件] [安装] 更改的差异是人类可读的，并且会通知您 npm 对您的 所做的任何更改
\nnode_modules，因此您可以注意到是否更新、提升了任何传递依赖项等。
避免引入错误和漏洞。
\n从纱线：
\n\n\n由于软件包作者是人，他们可能会犯错误，因此他们可能会在次要版本或补丁版本中发布意外的重大更改。如果您在无意中安装了此重大更改，则可能会产生不良后果，例如破坏生产中的应用程序。
\n
\n\n如果包作者是恶意的，或者受到恶意者的攻击并发布了错误的版本，您不希望该代码在您不知情的情况下最终运行。
\n
这是“无知论证”，是一个逻辑谬误。换句话说，“我不知道原因，所以没有”。
\n\n\n\n如果这个文件是自动生成的，我们为什么要提交它？为什么npm不能根据我的package.json重新生成。
\n
回应：生成并不是缺陷。生成 Git 提交哈希值；我们不应该使用git吗？事实是，锁文件不是从 package.json确定性生成的，因为它容易受到时间和npm 注册表中包的状态的影响。为了稳定性，它是快照。
\n解决签入锁定文件中的合并冲突是一个负担。
\n来自 npm：
\n\n\n从 开始，这些冲突可以通过手动修复任何冲突然后再次运行来
\nnpm@5.7.0解决。package.jsonnpm install [--package-lock-only]
从纱线：
\n\n\n当锁定文件中存在\xe2\x80\x99s合并冲突时，Yarn将在运行时自动为您处理冲突解决方案
\nyarn install。
https://engineering.fb.com/2017/09/07/web/announcing-yarn-1-0/
\n来自 pnpm：
\n\n\npnpm 可以自动解决
\npnpm-lock.yaml. 如果存在冲突，只需运行pnpm install并提交更改即可。
因此，所有包管理器都会自动解决锁定文件合并冲突。在旧版本中可能不是这样，但现在是这样。
\n唯一失败的情况是其package.json本身存在冲突，因为您无法从无效的package.json. 您必须手动解决这些冲突，因为无论如何您都必须这样做。
\n\n使用锁定文件会大大增加合并一个 PR 导致第二个 PR 与基础分支发生冲突的可能性。
\n
https://docs.renovatebot.com/noise-reduction/#lock-file-considerations
\n这是真实的。Git 提供程序（GitHub、GitLab 等）不会自动解决锁定文件冲突，因此这可能会增加合并的负担。然而，在权衡这一弊端时，请了解锁定文件通常不会更改；它们仅在package.jsondeps 更改时或开发人员专门更改文件或安装的文件时更改node_modulesdeps 时，它们才会更改。
如果差异工具显示锁文件差异，则会产生很多噪音。
\n这是事实，但这是一个工具问题，许多工具可以很好地处理（例如自动最小化、分页或虚拟滚动）。如果您根本不想看到锁定文件差异，请尝试git diff -- . \':(exclude)yarn.lock\'，或者将文件标记为二进制文件.gitattributes（但是，如果这对您很重要，您将看不到它的差异）。
\n\n\n为什么不通过去掉脱字符号和波形符（^ 和 ~）来硬编码依赖版本？
\n
这个想法是不使用范围package.json可以完成与使用锁定文件相同的事情。
这是错误的。即使您指定了确切的版本，您的依赖项也有自己的依赖项，这些依赖项可能使用其版本的范围，而不是确切的版本。因此，这最终不会锁定整个依赖关系树，而只会锁定其顶部。
\n这种反对意见的例子：
\n人们的观点是，图书馆需要对前沿部门做出反应，并且没有锁文件支持这一点。
\n从纱线：
\n\n\n有些人想知道为什么库应该使用锁文件......在开发库时使用锁文件会产生一种错误的安全感，因为您的用户可能安装与您不同的版本。
\n这在逻辑上似乎是有道理的，但是让\xe2\x80\x99s 更深入地研究这个问题。
\n
纱线文章深入探讨，以消除这种反对意见。请阅读它。
\n此论点中的一个常见错误是认为如果不提交锁文件，它就不存在。实际上，它仍然在您的计算机上，锁定您的依赖项。gitignoring the lockfile 并不能改善这种情况。
\n如果库维护者希望不断测试兼容性，那么他们应该在安装和构建库之前删除其锁定文件（无论锁定文件是否签入！）。与签入锁定文件的唯一区别是，发生这种情况时，您可以持久记录 node_modules 的状态，因此可以在将来重现它。
\n有像greenkeeper和renovate-bot这样的机器人可以做到这一点。Greenkeeper 提倡检查锁文件（Greenkeeper 和 Lockfiles：天作之合），renovate-bot 不表达任何意见，但会提交锁文件（如果存在）。
\n这是提到的一个声明（例如此处）：不同的操作系统生成不同的锁定文件内容。如果是这种情况，则这是一个错误。
\n然而，不同版本的npm（或任何包管理器）可能会产生不同的锁定文件输出。我还没有证实这一点，但假设如果是这样，那么为稳定付出的代价很小。为了解决这个问题，贡献者需要使用nvm之类的工具来切换他们的包管理器版本。
请参阅Snyk - 为什么 npm 锁定文件可能成为注入恶意模块的安全盲点
\n这是一个真正的风险。具有锁定文件的公共项目可能会收到带有锁定文件内容的恶意 PR，一旦分支被拉出并安装，这些内容可能会危及维护人员的计算机。
\n通过 CI 检查（例如lockfile-lint或简单的npm cior yarn --immutable（在 Yarn 1 上））来防御这种情况yarn --frozen-lockfile，并且可能ignore-scripts在您的npmrc.
每当您安装包含不受信任代码的软件包时，就会存在这种风险。
\n始终提交锁定文件。
\nNik*_*kar 10
是的， commit 是标准做法package-lock.json。
提交的主要原因package-lock.json是项目中的每个人都在同一个包版本上。
优点：
缺点：
npm install不会确保项目中的每个人都使用相同的包版本。npm ci将对此有所帮助。
全局禁用 package-lock.json
在终端中输入以下内容：
npm config set package-lock false
这真的像魔术一样对我有用
所有答案都说“是”，但这也取决于项目，文档说：
\n\n\npackage-lock.json 的一个关键细节是它无法发布，如果在顶级包以外的任何地方找到它，它将被忽略。
\n
这意味着您不需要在 npm 上发布您的package-lock.jsonfor 依赖项，但需要package-lock.json在存储库中使用来锁定测试依赖项的版本，构建依赖项\xe2\x80\xa6
但是，如果您使用lerna来管理具有多个包的项目，则应该package.json仅将其放在存储库的根目录中，而不是在使用npm init. 你会得到类似的东西：
.git\nlerna.json\npackage.json\npackage-lock.json <--- here\npackages/a/package.json\npackages/a/lib/index.js\npackages/b/package.json\npackages/b/lib/index.js\n| 归档时间： |
|
| 查看次数： |
401740 次 |
| 最近记录： |