迈向开源第一步，给fabric.js提PR

大家好，我是CC，在这里欢迎大家的到来～

开场

今天这篇文章主要是想分享一下给 fabric.js 从提 issues 到后边合并 PR 的过程。之前在公司业务中有了一些对 fabric.js 源代码的阅读、调试以及修改，就想着看看能不能给开源做些贡献；在测试了 fabric.js 最新版本也没有修复问题的情况下就开始尝试提 issues。

提 issues

新开 issues 按照规范填写发现的 Bug 的相关内容（可以参考别人 issues 的书写），像发现 Bug 的版本、环境、复现步骤、期望的结果和实际的结果等，需如实填写。

后续仓库主理人就会在这个 issues 下进行沟通，在这里也可以表明你正在尝试修复此问题，主理人也会告诉后续合并到哪些分支。

阅读开源库的文档

在开发前需要先阅读代码库文档，了解如何规范提问，如何提交 issues，如何参与问题的修复等等。这一步的需要详细阅读。

像 fabric.js 的贡献流程文档，从内容中可以看到它详细罗列一步步的操作以及鼓励参与，真的非常友好了。

Fork 代码开发

开发前需要 Fork 一份代码到个人的仓库中，如果之前 Fork 过导致代码长时间未更新的话需要点击"Update branch"拉去最新代码。

接下来把代码克隆到本地，基于 master 新建分支（分支名称可以参考原仓库其他人的分支命名）。

跑通测试用例

测试用例之前也没写过，这里仓库主理人也给了一部分帮助和建议。

当时写了个 unit 测试用例，然后需要执行 package.json 中的测试脚本，确保测试用例通过后再提交。

javascript 复制代码

describe('measuring, splitting', () => {
  it('measuring a single char', () => {
    cache.clearFontCache();
    const text = new FabricText('');
    const style = text.getCompleteStyleDeclaration(0, 0);
    const measurement1 = text._measureChar('a', style, '', style);
    const measurement2 = text._measureChar('a', style, '', style);
    expect(measurement1).toEqual(measurement2);
    const cacheKeys = cache.charWidthsCache
      .get(text.fontFamily.toLowerCase())
      ?.get('normal_normal')
      ?.keys();
    expect(cacheKeys?.next().value).not.toBe('undefineda');

提 PR

把功能分支通过 Github 平台的 Pull requests 模块进行提交，从图中可以看到是从个人仓库的 Fork 仓库的功能分支合并到原仓库的 master 分支进行的提交合并。这里也注意填写标题和描述。

等待与回复

在仓库主理人阅读了 Pull requests 后会进行评审，看是否缺少测试用例以及提审代码是否符合规范等等。这里需要多耐心沟通，可能主理人和我们有着时差。

耐心等待

在有主理人 review 代码后只需要耐心等待，在下一次版本更像时就会被合并到 master 以及新版本。

总结

整个流程走下来，我最深的体会是：开源社区远比想象中更友好。刚开始提 issue 时难免忐忑，担心问题太简单或表达不清晰，但实际上，维护者往往非常耐心，甚至主动引导你如何修复。从阅读贡献规范、跑通测试，到接受代码审查，每一步都是宝贵的学习。