为什么要保留它们，什么时候应该放弃它们？您是否遇到并思考过以下问题？什么是package-lock.json（或yarn.lock）？我们为什么需要它？我的package-lock.json文件有冲突我在提交时忽略了它我要删除它更糟的是，你可能已经删除了它并提交了你的PR或推送给master！如果是这种情况，那么您修改的源代码比预期的要大得多。您控制自己的源代码，但package-lock.json和yarn.lock文件确保您的第三方代码不会在提交之间更改在解锁包锁时将第三方包视为一等公民文件保密。许多开发人员只考虑更改自己的源代码，但通过npm和yarn等包管理器安装的第三方代码同样重要，甚至更重要。为什么？因为它们会导致难以追踪的错误。换句话说，如果没有包锁定文件，您将不知道代码中发生了什么变化，从而导致您可能会观察到错误。您可以盯着提交之间的代码差异并花费数小时思考这些更改不可能导致问题。没错，是您看不到的代码导致了问题。给你的第三方包应有的尊重，把它们当作你自己的代码。将您的程序包视为由多个开发人员提交给您的项目的二进制代码，就好像它是开源的一样让我们解决上面的问题。什么是包锁定文件？水果和蔬菜的比喻这样想，你喜欢吃水果和蔬菜。每个星期你都需要购买水果和蔬菜，所以你有一个很少改变的标准购物清单：每周购物清单：水果苹果葡萄西红柿蔬菜洋葱土豆南瓜你知道你的口味比这个好一点，所以你添加了一些关于每种水果和蔬菜的细节：每周购物清单：水果苹果：红葡萄：绿色西红柿：红色蔬菜洋葱：白色、红色或棕色土豆：洗净或去皮的南瓜：任何一种很好，我们有一份清单，非常详细，但我们的一些水果和蔬菜有一些变化空间。所以我们出去买了清单上的东西，最后得到了一张收据：收据-01/01/2020苹果-富士西红柿-红葡萄-大葱-棕色土豆-水洗南瓜-产地看看这里发生了什么？虽然我们没有指定某些水果和蔬菜的确切类型，但我们必须购买确切的。现在，当我们回到家，吃我们的苹果，煮我们所有的蔬菜时，我们对自己的选择感到非常满意，以至于我们保留收据并在下次购物时随身携带，连同我们的清单。由于我们有收据列出了我们上周购买的物品，因此我们本周购买了完全相同的物品。这可能会永远持续下去，但假设我们对苹果的口味发生了变化，所以我们写了一个新清单：每周购物清单任何现在，当我们去购物时，我们将不得不购买某种青苹果。在结帐时，我们收到了以下收据：收据-02/01/2020苹果-南方青苹果西红柿-红葡萄-大葱-棕色土豆-水洗南瓜-产地我们购买了与上周完全相同的东西，除了我们更换了我们的苹果配南方格兰尼史密斯苹果！因为我们保留了收据，所以我们能够记住我们喜欢的所有水果和蔬菜，并继续购买相同的。但是如果我们把收据扔掉怎么办？我们必须从头开始，最后可能会吃到我们不喜欢的水果和蔬菜。得到了购物清单、收据、水果和蔬菜，但这是一篇关于软件工程的文章？让我们回到软件的角度：购物清单代表你的package.json文件每个水果和蔬菜代表一个包裹水果或蔬菜的类型代表那个包裹的确切版本或可接受的版本范围收据代表你的包裹锁.json或yarn.lock文件当我们保存收据，也就是我们的包锁（packagelock）文件时，我们可以确保我们得到的是同一个包的版本，直到我们的购物清单，也就是我们的package.json文件发生变化。如果我们丢失了包锁定文件，我们很可能会得到一个不是我们期望的包。包锁定文件保持提交不可变如果您在您选择的版本控制工具中打开提交图，图中的每个尖点代表一个代码版本，如果该版本的代码被检索（拉），它应该是无论谁在何时取回它都是一样的。如果您的代码库包含具有依赖项的package.json文件而不是package-lock.json或yarn.lock文件（或其他包管理器用于锁定包版本的另一个文件），则情况并非如此。如果在不同时间访问提交，我们可以获得不同版本的包。这是因为包的新版本一直在发布，我们已经允许在我们接受的某些版本中存在差异。例如：{"name":"my-angular-app","version":"1.0.0","scripts":{"ng":"ng","start":"ngserve","build":"ngbuild","test":"ngtest","lint":"nglint","e2e":"nge2e"},"private":true,"dependencies":{"@angular/animations":"^8.2.1","@angular/common":"^8.2.1","@angular/compiler":"^8.2.1","@angular/core":"^8.2.1","@angular/forms":"^8.2.1","@angular/http":"^8.0.0-beta.10","@angular/platform-b??rowser":"^8.2.1","@angular/platform-b??rowser-dynamic":"^8.2.1","@angular/router":"^8.2.1","core-js":"^2.5.4","csstype":"^2.5.8","ng2-file-upload":"^1.3.0","rxjs":"~6.5.3","zone.js":"~0.9.1","typescript":"~3.5.0"},"devDependencies":{"@angular-devkit/build-angular":"~0.803.19","@angular/cli":"^8.3.19","@angular/compiler-cli":"^8.2.1","@angular/language-service":"^8.2.1","@nguniversal/express-engine":"^7.0.2","@types/jasmine":“~2.8.8”，“@types/jasminewd2”：“~2.0.3”，“@types/node”：“~8.9.4”，“codelyzer”：“~4.5.0”，“茉莉花核心”":"~2.99.1","jasmine-spec-reporter":"~4.2.1","karma":"~3.0.0","karma-chrome-launcher":"~2.2.0",“karma-coverage-istanbul-reporter”：“~2.0.1”，“karma-jasmine”：“~1.1.2”，“karma-jasmine-html-reporter”：“^0.2.2”，“量角器”:"~5.4.0","ts-node":"~7.0.0","tslint":"~5.11.0"}}注意所有的~和^？如果这些包在不同时间安装，可能会导致下载这些包的不同版本。尽管package.json文件存在差异，但保留package-lock.json或yarn.lock文件将锁定这些版本。我会让一些数字来说话，初始yarn安装后node_modules文件夹中的文件大小和数量，删除node_modules并重新安装后文件的大小和数量，保留yarn.lock以上文件大小和计数的细分表明没有任何内容删除node_modules并重新安装包后，node_modules文件夹中发生了更改。但是删除node_modules文件夹和yarn.lock文件后，多了1507个文件，总大小超过7mb。这些额外的文件到底是什么？其中一些文件是否进入了我们应用程序的运行代码？可怕的是我们可能永远不知道。删除或不提交您的package-lock.json或yarn.lock就像在说“提交我的代码并随机修改我们其余源代码的X%”删除包锁是否安全？您是否曾经对跨越许多不相关功能的代码库进行过重大重构？也许你有意更新了一个主要的库，比如一个前端框架，但你不确定什么可能会被破坏，所以你对你的应用程序运行了一个完整的回归测试？好吧，如果您要删除包锁定文件，我可能会建议执行相同的步骤。如果更改代码的大部分横截面会导致您运行完整的回归测试，那么您还应该更改大部分第3方代码所有~和^可以更新到最新的补丁和次要版本），然后可以删除包锁定文件。删除包锁定文件可能是利用package.json文件的强大功能的好方法，但要准备好运行完整的回归测试或解决任何意外行为摘要npm包不会被删除，除了在某些极端情况下，任何给定版本也不会被修改，它们是不可变的。对于任何给定的提交，你自己的代码也应该是不可变的，如果Yarn用户使用npm或yarn.lock，允许这样做的机制称为package-lock.json文件。此文件的存在确保为给定的提交安装相同的包版本，因此无论谁在何时使用它，您自己的源代码和第三方打包的代码都是相同的。删除或不提交这些文件可能会导致应用程序出现不可预测的行为，因为对于同一次提交，包的实际安装版本可能会随着时间的推移而改变，如果发现错误是由错误的包引起的，那么可能会很困难追踪他们。因此，建议您在不删除这些文件的情况下提交，除非您打算根据package.json规范更新您的包并准备彻底测试或快速修复在生产中发现的任何错误。感谢阅读，我希望这能解释package-lock.json和yarn-lock.json文件。相关链接：package-lockyarn-lock专注于大前端技术和程序员成长。如果您有一些启发和帮助，可以关注、收藏或留言讨论。这是对作者最大的鼓励。作者简介：Web前端工程师，全栈开发工程师，持续学习者。
