2021年在Github上提交Pull Request的经验总结

前端开发会经常使用到其他团队或个人开发的开源项目,自己也写过一些小项目自娱自乐。但对别人的项目几乎没有什么贡献,issue和PR没怎么提交过。离开公司后,自己有了更多的时间去深入的研究一些开源项目。后来发现,参与别人的开源项目没有那么困难,甚至一些知名的开源项目也有很多被人忽视的细节问题,自己作为路人也可以很好的参与其中。2021年8月份开始,决定开发或者参与一些开源项目,提交一些issue和PR。

2021年9月,自己想学一下怎么用TailwindCSS,顺便用它重写了 Jekyll 个人博客的 UI 部分,把这个博客模板分享到了 GitHub 上,并且找到了一个叫 awesome-tailwindcss 的项目展示库,就向这个 repo 提交一个 PR,这也是今年的第一个 PR。过了不到一天就被 merge 了,然后过了不到一个月的时间,获得了 3 个star。感觉应该和这次提交有关,之前没有宣传过的开源项目几乎一个 star 都没有。

经验一:

  1. 开源项目要尽可能分享到更多人能看到的地方

这个项目就告一段落之后,到了10月份,开发了一个TypeScript工具库, rollup-typescript-babel-starter,搞清楚了如何在项目中一起使用 tscbabel。对比了tsc和 Babel 打包后的效果,决定使用 Babel 来编译(严格的说是转译)TypeScript。期间查阅官方文档中发现了一个问题,Babel 官方文档中的 @babel/env 已经修改成了 @babel/preset-env 。但是,Guide 页面上依然使用 @babel/env 感觉语义上不统一。于是提交了一个 PR,把 Guide 页面内所有的 @babel/env 改成了 @babel/preset-env,但是在PR的描述上出了一些问题,我说的是在文档的其他地方找不到@babel/env(表面现象),而不是说现在更新(问题本质)。好在 Babel 的评审人员明白了我的意思,同意了我的修改意见,并规范了我要描述的问题的内容。当在官网上看到自己提交的修改时,真的有了一种参与其中的感觉

经验二

    1. Babel 团队目前的工作效率依然很高,对他人的贡献积极回应
    1. 提交 PR 时,要对问题的认识足够清晰,同时描述PR要解决的问题时要突出重点,避免让评审人员误解(这次比较幸运)

当然,期间提交的 PR 也有被拒的时候。开发完上个项目后,搞明白了一些发布 npm 包的知识点,就想在社区中找一些这方面可以改进的开源项目。就看了一下 d3 的 Rollup 是怎么配置的,感觉 Mike Bostock 配置的比较实用,没有很多花里胡哨的地方,于是就试探性的提交了一个 PR,但作者不认为我的改进方案足够的重要,而且每次修改都会影响到与其相关的30多个库,所以就拒绝了。虽然被拒了,但自己能收到业内的大牛的回复也是蛮激动的。

经验三

    1. 提交 PR 之前,可以观察作者项目之前提交的issue 和 PR,观察代码风格和整体结构。有些人的代码注重细节,可以提一些typos和细节优化,有些人注重实用(就像 Mike Bostock)一样,功能没有问题就不用改了。

11月,决定开发一个图形基础库,需要用到一些几何和数学方面的 JavaScript 的 API。查看MDN文档的时候,看到描述 Math.log() 的 Latex 公式写的有问题。于是提交了一个 PR,合并后,利用经验三也在其他的 API 文档中找到了类似的问题,于是也提交了相似的 PR。自己也没想到能在MDN文档中找到问题。

经验四

    1. 如果拿不准可以提交一个试探性能的 PR,如果作者同意合并。过一段时间将进一步的改进再提交一个 PR。不要去花了很多时间,改了很多,最后提交被拒绝,那就有点浪费时间了。

12月,由于项目需要使用 codemirror 6,需要开发一个自定义的语法高亮系统。但是项目 clone 下来之后没有跑通。后来发现是作者升级了依赖库,原有的代码没有改。我就顺手改了一下,提交了 PRMarijn Haverbeke,合并了我的提交。我之前读过他写的Eloquent JavaScript,感觉还是挺奇妙的。

今年参与的开源项目只有这么多,没什么有技术含量的提交。没有刻意参与,但的确有意识的参与了。现在每个月基本都可以找到可以提交 PR 的项目。参与开源真的没有想象的那么难,那些业内大牛们也没有想象的那么高冷,就算知名的开源项目也会有一些很难注意到的细节问题。今年快结束了,2022年给自己立个目标,开发一个让自己满意的开源项目。