package-lock.json和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

苹果 - 富士
番茄 - 红色
葡萄 - 绿的
洋葱 - 棕色
土豆 - 洗净
南瓜 - 原产地
复制代码

看到这里发生了什么吗？尽管咱们没有具体说明一些水果和蔬菜的确切类型，但咱们不得不购买确切的类型。

如今，当咱们回到家，吃了咱们的苹果，煮了咱们全部的蔬菜，咱们对咱们的选择很是满意，因此咱们保留着收据，下次带着它去购物，连同咱们的清单。

由于咱们有收据，上面列出了咱们上周购买的商品，因此本周咱们购买的商品彻底相同。

这可能会一直持续下去，可是假设咱们对苹果的口味发生了变化，因此咱们写了一个新的清单：

每周购物清单

水果：
    苹果：绿的
    葡萄：白的
    番茄：红色
蔬菜：
    洋葱：白的红的或者棕色的
    土豆：洗干净的或刨皮了的    
    南瓜：任何一种
复制代码

如今，当咱们去购物时，咱们将不得不购买某种绿色苹果。结算时，咱们获得了以下的收据：

收据- 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 文件。

---

相关连接：

• package-lock
• yarn-lock

---

原文：levelup.gitconnected.com/package-loc…

翻译：Dunizb

---

关注公众号:“前端外文精选”，送精品视频视频教程大礼包！