在当今的前端工程化领域，第三方库的使用已经成为标配。然而，不可避免的是，这些库可能会存在bug，或者是库的一些功能并不能满足需要，需要修改库的某个功能，或添加功能。当遇到这种情况时，我们应该如何应对？本文将介绍三种解决第三方库bug的方法，并重点介绍使用 patch-package库来修复bug的全过程。
方法一：提issues给第三方库的作者，让作者修复
这个方式是比较常见的解决方式了，但有几个缺点：
库作者不维护这个库了，那提issues自然就没有人close了，gg 库作者很忙，或者项目缺乏活跃的贡献者，导致问题可能长时间都不懂响应，那如果你这个项目很急的话，那gg bug或者功能的优先级不高，库作者先解决其他高优先级的，或者他不接受你的建议或者及时修复问题，那gg 还有可能出现的沟通成本，以确保库作者完全理解了问题的本质和重要性。
那如果库作者很勤奋，每天都在维护，对issues的问题，都满怀热情的进行解决，那我们可以按照以下流程进行提issues：
发现bug：在使用第三方库时，发现了一个bug。
复现bug：在本地环境中尝试复现该bug，并记录详细的复现步骤。
提交issues：访问第三方库的GitHub仓库，点击“New issue”按钮，填写以下信息：
标题：简洁地描述bug现象。 描述：详细描述bug的复现步骤、预期结果和实际结果。 环境：列出你的操作系统、浏览器版本、库的版本等信息。
等待回复：作者可能会要求你提供更多信息，或者告诉你解决方案。耐心等待并积极配合。nice
方法二：fork第三方库，修复好bug后，发布到npm，项目下载自己发布的npm包
这个方式也有局限性：
维护负担：一旦你fork了库，你需要负责维护这个分支，包括合并上游的更新和修复新出现的bug。 长期兼容性：随着时间的推移，原库和新fork的库可能会出现分歧，使得合并更新变得更加困难。 版本管理：需要管理自己发布的npm包版本，确保它与其他依赖的兼容性。 社区隔离：使用自己的fork可能会减少与原社区的合作机会，错过原库的其他改进和特性。
那如果你觉得这个方式很不错，那最佳实践是这样的：
步骤 1: Fork 原始库
访问原始库的GitHub页面。 点击页面上的“Fork”按钮，将库复制到你的GitHub账户下。
步骤 2: 克隆你的Fork
git clone https://github.com/your-username/original-repo.git
cd original-repo
步骤 3: 设置上游仓库
git remote add upstream https://github.com/original-owner/original-repo.git
这样当作者更新维护库的时候，可以获取上游仓库的最新更新。
步骤 4: 创建特性分支
git checkout -b fix-bug-branch
步骤 5: 修复Bug
在这个分支上，进行必要的代码更改来修复bug。
步骤 6: 测试更改
在本地环境中测试你的更改，确保修复了bug并且没有引入新的问题。
步骤 7: 提交并推送更改
git add .
git commit -m "Fix bug description"
git push origin fix-bug-branch
步骤 8: 创建Pull Request（可选）
如果你希望原始库接受你的修复，可以向上游仓库创建一个Pull Request。
步骤 9: 发布到NPM
如果原始库没有接受你的PR，或者你需要立即使用修复，可以发布到NPM：
登录到NPM。
npm login
这个地方有个坑点，就是你使用了npm镜像需要将镜像更改为npm官方仓库：
npm config set registry https://registry.npmjs.org
修改 package.json中的名称，避免与原始库冲突，例如添加你的用户名前缀。
{
"name": "@your-username/original-repo",
// ...
}
更新版本号。
npm version patch
发布到NPM。
npm publish
步骤 10: 在你的项目中使用Forked库
在你的项目package.json中，将依赖项更改为你的forked版本。
{
"dependencies": {
"original-repo": "^1.0.0",
"@your-username/original-repo": "1.0.1"
}
}
步骤 11: 维护你的Fork
定期从上游仓库合并更新到你的fork，以保持与原始库的同步。
git checkout master
git pull upstream master
git push origin master
最佳实践总结
保持与上游仓库的同步。 清晰地记录你的更改和发布。 为你的fork创建文档，说明它与原始库的区别。 考虑长期维护策略，如果可能，尽量回归到官方版本。
方法三：使用patch-package库来修复
patch-package 是一个非常有用的 npm 包，它允许我们在没有修改原始 npm 依赖包的情况下，对 npm 依赖进行修复或自定义。这在以下场景中特别有用：
当你发现一个第三方库的 bug，但作者还没有修复它，或者修复后的版本尚未发布。 当你需要对第三方库进行微小的定制，而不想维护一个完整的分支或分叉。
patch-package 的工作原理
patch-package 的工作流程通常如下：
修改 node_modules中的依赖包文件。运行 patch-package命令，它会生成一个补丁文件，通常是.patch文件，保存在项目根目录下的patches文件夹中。在 package.json的scripts部分添加一个脚本来应用这些补丁，通常是在postinstall阶段。将生成的 .patch文件提交到版本控制系统中。当其他开发者运行 npm install或yarn安装依赖时，或者 CI/CD 系统构建项目时，这些补丁会被自动应用。
但使用这种方式也有前提：
1. 潜在冲突：如果第三方库的官方更新解决了相同的bug，但采用了不同的方法，那么你的补丁可能会与这些更新冲突
2. 库没有源码：这种方式是在node_modules里对应的包进行修改，如果包是压缩后的，那就没办法改了，所以只能针对node_modules里的包有源码的情况下。
最佳实践：
步骤 1：安装patch-package postinstall-postinstall
postinstall-postinstall，作用是 postinstall 脚本在 Yarn 安装过程中运行。
yarn add patch-package postinstall-postinstall --dev
步骤 2：配置 package.json
在你的 package.json 文件中，添加一个 postinstall 脚本来确保在安装依赖后应用补丁：
"scripts": {
"postinstall": "patch-package"
}
步骤 3：修复依赖包中的 bug
假如vue3有个bug，我们直接在 node_modules/vue/xxx 中修复这个 bug。
步骤 4：创建补丁
修复完成后，我们运行以下命令来生成补丁：
npx patch-package example-lib
这会在项目根目录下创建一个 patches 文件夹，并在其中生成一个名为 vue+3.4.29.patch 的文件（假设vue当前库的版本是3.4.29）。
步骤 5：提交补丁文件到代码库中
现在，我们将 patches 文件夹和里面的 .patch 文件提交到版本控制系统中。
git add patches/example-lib+1.0.0.patch
git commit -m "Add patch for vue3.4.29"
git push
步骤 6：安装依赖并应用补丁
就是其他同事在下载项目或者更新依赖后，postinstall 脚本会自动运行，并应用补丁。
npm install
# 或者
yarn install
当 npm install 或 yarn install 完成后，patch-package 会自动检测 patches 文件夹中的补丁，并将其应用到对应的依赖上。
志哥我想说
遇到第三方库的bug时，我们可以选择提issues、fork并发布自己的npm包，或者使用patch-package进行本地修复。当然你还可以有：
使用替代库 社区支持
每种方法都有其适用场景，根据实际情况选择最合适的方法。希望本文能帮助你更好地应对第三方库的bug问题，或者面试或者技术分享等。
本文作者：_志哥_
原文链接：https://juejin.cn/post/7418797840796254271
