某次前端需求开发中，新增了一个 npm 包，在进行合码时发现 lockfile 出现冲突。
lockfile，即包管理工具的 lock 文件，比如
package-lock.json、yarn.lock、pnpm-lock.yaml
手动解冲突非常低效，又容易出错。以下是几种常用的解决方案：
- 删掉 lockfile，后面再重新安装依赖
- 重置为其中一个分支的 lockfile，后面再重新安装依赖
- 运行依赖安装命令，利用包管理工具自带的机制修复 lockfile 冲突
方案 1 会丢失 lock 记录，通常不会选择。
那方案 2 和方案 3 可行么？需要注意什么问题？ 本文将对这些问题进行讨论，并在最后给出最佳实践。
如果不想关注细节，也可以滑到最后直接查看「最佳实践」。
在软件开发领域，代码质量一直是开发者们关注的焦点之一。为了更好地评估和管理代码质量，人们逐渐引入了量化指标的概念。
本文将从代码质量的定义、定性方法、量化指标等方面展开讨论。
对于使用 npm 的前端项目，在分支合并时经常会遇到 package-lock.json 冲突。此时直接执行 npm install 命令，npm 会自动帮忙解决冲突。
但这是否存在什么问题？又该如何解决？文本将来探讨这个话题，预期收获有：
- 了解
npm install自动解决合并冲突的原理 - 了解合并冲突修复算法存在的问题，以及如何解决
# 1. 前言
ESLint 是前端最流行的代码校验工具，它提供了许多插件 (plugins) 和共享配置 (extends) 来扩展其功能。然而，在安装某些共享配置时，用户常常还需要安装一些插件依赖项。
以 eslint-config-airbnb（最流行的可共享配置之一）为例，除了安装 eslint-config-airbnb 外，还需要安装众多对等依赖（peerDependencies），比如 eslint-plugin-import、eslint-plugin-jsx-a11y 、eslint-plugin-react、eslint-plugin-react-hooks 等等。
本次精读的文章是：Eslint 的实现原理，其实挺简单 - 掘金
# 引言
团队一旦变大，往往有定制团队 lint 规范的诉求：一是知道如何配置规则，二是知道如何编写规则。
目前前端领域最流行的 lint 工具是 eslint ，我们只有了解了它的实现原理，才能更好的制定规范。
本次精读的文章，详细介绍了 ESLint 的实现原理。「ESLint 执行步骤」一节会对这篇文章进行总结，然后精读思考部分会重点探讨 ESLint 的解析细节和性能优化策略。