package-lock与yarn.lock区别
你是不是遇到和思考过下⾯的问题？
什么是package-lock.json（或yarn.lock）？
我们为什么需要它？
我的package-lock.json⽂件中有冲突
我提交时会忽略它
我要把它删掉
更糟糕的是，您可能已经删除了它，并提交了您的 PR 或 push 到master！
如果是这种情况，那么您已经修改了⽐预期⼤得多的源代码。
您可以控制⾃⼰的源代码，但package-lock.json和yarn.lock⽂件可确保您的第三⽅代码在两次提交之间不会发⽣变化
将第三⽅包视为⼀等公民
在解开包锁⽂件的秘密时，理解这⼀点⾄关重要。许多开发⼈员只考虑更改⾃⼰的源代码，但是通过软件包管理器（如npm和yarn）安装的第三⽅代码也同样重要，甚⾄更多。
为什么？因为它们会导致很难追踪的bug。
换句话说，如果没有package lock⽂件，您就不知道代码中发⽣了什么变化，从⽽产⽣了您可能观察到的bug。您可能会盯着提交之间的代码差异，花上⼏个⼩时思考这些更改不可能导致这个问题。
你是对的，这是你看不到的代码导致问题。
给予您的第三⽅软件包应有的尊重，并将他们视为您⾃⼰的代码。
将您的包看作是由多个开发⼈员提交给您的项⽬的⼆进制代码，就好像它是开源的⼀样
让我们解决以上⼏点。
什么是 package lock ⽂件？⽔果和蔬菜的⽐喻
这样想吧，你喜欢吃⽔果和蔬菜。每周您都需要购买⽔果和蔬菜，因此您有⼀个标准的购物清单，很少更改：
每周购物清单：
⽔果
蔬菜
现在，您实际上喜欢某些种类的⽔果和蔬菜，因此您想使列表更具体：
每周购物清单：
⽔果
苹果
葡萄
番茄
蔬菜
洋葱
⼟⾖
南⽠
你知道你的⼝味⽐这个好⼀点，所以你添加了⼀些关于每种⽔果和蔬菜的细节：
每周购物清单：
⽔果
苹果：红⾊
葡萄：绿⾊
番茄：红⾊
蔬菜
洋葱：⽩⾊，红⾊或棕⾊
⼟⾖：洗⼲净的或刨⽪了的
南⽠：任何⼀种
好的，我们有清单，⽽且相当详细，但是我们的⼀些⽔果和蔬菜还有⼀些变动的空间。所以我们出去买了清单上的东西，最后得到了⼀张收据：
收据 - 01/01/2020
苹果 - 富⼠
番茄 - 红⾊
葡萄 - 绿的
洋葱 - 棕⾊
⼟⾖ - 洗净
南⽠ - 原产地
看到这⾥发⽣了什么吗？尽管我们没有具体说明⼀些⽔果和蔬菜的确切类型，但我们不得不购买确切的类型。
现在，当我们回到家，吃了我们的苹果，煮了我们所有的蔬菜，我们对我们的选择⾮常满意，所以我们保留着收据，下次带着它去购物，连同我们的清单。
因为我们有收据，上⾯列出了我们上周购买的商品，所以本周我们购买的商品完全相同。
这可能会⼀直持续下去，但是假设我们对苹果的⼝味发⽣了变化，所以我们写了⼀个新的清单：
每周购物清单
⽔果：
苹果：绿的
葡萄：⽩的
番茄：红⾊
蔬菜：
洋葱：⽩的红的或者棕⾊的
⼟⾖：洗⼲净的或刨⽪了的
南⽠：任何⼀种angular安装
现在，当我们去购物时，我们将不得不购买某种绿⾊苹果。结算时，我们得到了如下的收据：
收据- 02/01/2020
苹果 - 南⽅青苹果
番茄 - 红⾊
葡萄 - 绿的
洋葱 - 棕⾊
⼟⾖ - 洗净
南⽠ - 原产地
我们已经购买了与上周完全相同的东西，除了我们的苹果换成了南⽅青苹果！
因为我们保留了收据，所以我们能够记住我们喜欢的所有⽔果和蔬菜，并继续购买相同的⽔果和蔬菜。
但是，如果我们扔掉收据怎么办？我们必须从头开始，并可能最终得到我们不喜欢的⽔果和蔬菜。
得到它了购物清单、收据、⽔果和蔬菜，但这是⼀篇有关软件⼯程的⽂章？
让我们重新回到软件⾓度：
1. 购物清单代表您的 package.json ⽂件
2. 每个⽔果和蔬菜代表⼀个package
3. ⽔果或蔬菜的类型代表该package的确切版本或可接受版本的范围
4. 收据代表您的 package-lock.json 或 yarn.lock ⽂件
当我们保存收据，也就是我们的 package lock（包锁定）⽂件时，我们能够确保获得相同package的版本，直到我们的购物清单，也就是我们的 package.json ⽂件发⽣了变化。
如果我们丢掉包锁定⽂件，很可能最终得到的包不是我们期望的。
包锁定⽂件使提交保持不变
如果在所选的版本控制⼯具中打开提交图，则图上的每个尖点都代表⼀个版本的代码，如果该代码的版本被检索（pull）是不可变的，则⽆论谁以及何时检索它都应该是相同的。
如果您的代码库包含具有依赖性的 package.json ⽂件，⽽不是package-lock.json 或 yarn.lock ⽂件（或其他软件包管理器⽤来锁定软件包版本的另⼀个⽂件），则不是这种情况。如果在不同的时间访问提交，我们可以得到不同版本的软件包。
这是因为包的新版本⼀直都在发布，⽽且我们已经允许在⼀些我们将接受的版本中存在差异。例如：
{
"name": "my-angular-app",
"version": "1.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
},
"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-browser": "^8.2.1",
"@angular/platform-browser-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",
"jasmine-core": "~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",
"protractor": "~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 并重新安装，删除 yarn.lock 之后的⽂件⼤⼩和数量
上述明细表⾯，在删除 node_modules 并重新安装包之后，node_modules ⽂件夹没有发⽣任何变化。
但是，在删除了 node_modules ⽂件夹和 yarn.lock ⽂件之后，⼜有了1507个⽂件，它们的⼤⼩总计超过7mb。
这些多余的⽂件到底是什么，其中⼀些会进⼊我们应⽤程序的运⾏代码中吗？可怕的是我们可能永远不会知道。
删除或不提交您的package-lock.json 或 yarn.lock 就像说"提交我的代码并随机修改我们源代码其余部分的 X%"
删除程序包锁定是否安全？
您是否曾经在代码库上做过跨越⼤量不相关的功能的重⼤重构？也许你有意更新了主要库，例如前端框架，你不确定什么，如果有什么可能会坏掉，所以你在你的应⽤程序上运⾏了⼀个完整的回归测试？
好吧，如果您要删除软件包锁定⽂件，我可能会建议您执⾏相同的步骤。
如果更改代码的⼀个⼤的横截⾯会导致您运⾏⼀个完整的回归测试，那么也应该更改您的第三⽅代码的⼀个⼤的⽐例
如果您确实想根据 package.json ⽂件获取最新最好的软件包（所有〜和 ^ 都可以更新为最新的补丁程序和次要版本），则可以删除软件包锁定⽂件。
删除程序包锁定⽂件可能是利⽤package.json⽂件的强⼤功能的⼀种好⽅法，但请准备运⾏完整的回归测试或解决任何意外⾏为
总结
除了在某些极端情况下，npm包不会被删除，任何给定的版本也不会被修改，他们是不可变的。
对于任何给定的提交，您⾃⼰的代码也应该是不可变的，如果对于 Yarn ⽤户使⽤ npm 或 yarn.lock，则允许这样做的机制称为 package-lock.json ⽂件。
此⽂件的存在可确保针对给定的提交安装相同的软件包版本，因此⽆论谁使⽤它，何时使⽤它，您⾃⼰的源代码和第三⽅打包的代码都是相同的。
删除或不提交这些⽂件可能会导致应⽤程序发⽣不可预测的⾏为，因为对于同⼀次提交，软件包的实际安装版本可能会随着时间⽽变化，如果发现错误是由错误的程序包引起的，则可能很难追踪到它们。
因此，建议您提交⽽不删除这些⽂件，除⾮您打算根据 package.json 规范更新软件包，并且准备进⾏彻底的测试或快速修复⽣产中发现的所有错误。
感谢您的阅读，我希望这能解释 package-lock.json 和 yarn-lock.json ⽂件。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。