前言

在这篇文章的最开始，先说明一下本篇没有什么过多的技术点，我是当作随笔来写的。对于很多开发的同行来说，这篇文章的内容或许也非常简单，因为就是讲了一个简单的PR（pull request）的过程，但是对于还没有给开源贡献过代码但是像曾经的我一样好奇且忐忑想参与开源的同学来说或许会是一篇好的指引手册。所以稍作犹豫，我还是决定写下这一过程，同时也算是记录我与 Varlet 的相遇相知。

一切的开始

说实话，我像个二傻子进城感叹大城市的繁华一样感叹着这份代码。我原本是看一些网上的教程自己写组件库，内心滋滋然，表示写一个库也就那么回事。但小丑竟是我自己，觉得简单是因为设计的少，考虑的少，眼界的狭窄让人看到的事务的难度是完全不同的。也就是在 varlet 中，我看到了一个好的组件库应该包含的 cli 命令工具、组件设计、文档设计、演示工具、版本控制、单元测试、环境适配、插件支持以及对依赖的源码的理解等。可能很多人还是不屑，现在流行的组件库哪一个不是这样？那雀氏，好的组件库都是必备这些点的，但其实让我惊叹和振奋的是，valert 是作者个人维护的仓库。没错，没有背靠公司，没有平台资源，完全是作者个人维护起来的，当然还有围绕在作者身边的一堆舔狗们（这是后来才知道的🐶）。并且发现作者还是跟我在一个城市，想要膜拜的心顿时砰砰跳个不停。

所以抱着虽然我很菜，但是我想跟大佬混的心态扫码入了群...从此入了豪门深似海、一见杨过误终身。

入群的心声

从 varlet 的 readme 提供的二维码加了群后，我便开始了讨论（水群）之旅。经过一些了解后，我发现群里好几个居然都跟我是同城，只能说不愧是耗子君和他的七个小矮人吧。很多人可能没感觉，当程序猿在自己的世界里固步自封的时候，往往就是退步的开始，所以在我发现同一个城市有这么多优秀的同行，我的兴奋是无法抑制的。有这种兴奋感不仅是自己可以去学习技术，增加自己的竞争力，更是因为可以结交到新的朋友。所以当时内心只有一个想法：我要入伙！

作为一个程序员，想要入伙，应该做什么呢？答案当然是，show your code！贡献你的代码，是让其他人认识你的最好的途径。

但是说实话，虽然写了有三年的代码了，但是对于给开源做贡献的经验我当时并不多，只是零零散散的提了一些 issue。所以这里我想说一下，对程序员来说，拓展自己眼界和技术的永远都是看别人的代码以及学习如何写别人好的代码，所以我鼓励小白们积极去 github 参与开源的讨论和贡献。

所以虽然心里有些打鼓，但我还是决定，冲了！

开始混代码

🐔然是混代码，那么一定要从库当前的功能去看有什么需求。我当时给 varlet 的代码分为两部分：一是支持组件功能和环境的基建类或者说工具类代码，二是组件的业务代码，而我打算从最简单的业务代码入手。

对着 varlet 的文档，当时大晚上我盯了俩小时，最后对着面前的 badge 组件：

我在想：如果这个内容过长怎么办？要是完全由内容撑开，那么 badge 显然会太宽，如果不撑开，那么又无法显示完全。

抱着这个想法，我定了一个后来觉得天真的需求：给定一个最大长度 maxLength 属性，内容字符串超过这个长度就截取掉并拼接...。我想，很多同学在做自己的业务时，没少干这事吧？于是从这么个简单的小需求，我做了下面的事情：

1. fork 仓库

这一般是给开源贡献代码标准流程的第一步，那就是将源仓库 fork 进自己的仓库。因为开源的库虽然大家都可以看得到以及克隆下来，但是肯定不是每个人都有修改的权限，所以要走一个 pull request 的流程，即拉取请求，从另外一个仓库发起一个向源仓库的申请，告诉作者：我修改了一些代码，你看看，可不可让我进去😏？当作者同意你的请求后，就会将你的代码合并进源仓库，从此，仓库的贡献者中就包含了你的大名了！

这一步很简单，看仓库的 github 页面，我们点击fork：

就会跳转到下面：

这里就是告诉我们，将源仓库克隆一份到你自己的仓库，由于我自己已经 fork 过了，所以上面看到的名字是 varlet-1，如果是没有 fork 过的话应该是完全同名的。然后我们继续点击 Create fork 就好了。然后在我自己的账号下，就会出现一个同样的 varlet 仓库。

2. 本地开发

当我们有了自己 fork 后的仓库后，接下来就是我们平时正常的开发流程了。克隆到本地、运行、修改、提交，push，这些操作大家肯定都很熟悉了。但这里需要强调的一点是：当你是参与开源组件库时，贡献代码前一定要详细阅读仓库的 README 文件，因为里面大多都会写着如何本地运行的步骤和环境依赖，很多还有对贡献代码会单独写流程和注意事项。

varlet 就是这样，readme 中提供了贡献代码指导的入口：

点进去是这样的：

可以看到，这里面说的非常详细了，将如何为此仓库贡献的步骤都列了出来。我箭头指的地方则是非常需要注意的地方，包括了初始化依赖环境、运行、跑单元测试和修改测试快照。只有走过这里的每一道步骤，代码才能真正在本地修改运行和向源仓库发起PR。

3. 提PR

我这里省去了开发具体代码的步骤，因为这次的代码真的非常简单，大家可以到当时的PR直接看：Pr badge max length by dyggod

我在这里只讲一下如何从自己的仓库向源仓库提PR。当我们在自己的仓库的一个新分支上做完自己的修改并确保单元测试没问题后，将分支 push 到自己的仓库。然后我们在 github 上就可以看到下面这样：

可以看到我现在是在 PR-teach 这个分支上，因为是刚刚 push 上去，所以最上面会显示最新的分支提示。无论在哪一块，我们都可以去点击 pull request 的操作，接着如下：

这个页面中最上面是合并的去向，即从哪个仓库的哪个分支将要合并到哪个仓库的哪个分支。我这里是从我的仓库的 PR-teach 分支合并到 varlet 的 dev 分支。然后我们按照 PR 的模板填写描述信息，需要再次确认是否跑过了代码的 lint 检查和单元测试。最后我们点击 Create pull request 就好了。然后在 varlet 的源仓库的 pull request 中就会出现这个 PR，等待作者的 code review。具体是什么样子的，可以直接在上面我贴的 PR 的链接里面看。

4. code review

code review 这个词无论是小白还是老鸟都不陌生，好的代码一定是需要审查的，一点是要审查需求合理性，一点是要审查代码实现中存在的问题。这一点从 varlet 就能看出来。经过我上述的步骤，其实我已经将我一开始想做的功能提交了，我心里想的是这么一个小小的功能应该没有问题。然而其实并不是，大家进到我上面的 PR 中，从其中的对话可以感受的出来，varlet 的作者耗子君之所以能将这个库维护的很好，就是因为他从真正的使用角度和通用性去考虑的。

在我最开始的想法中，我想对 badge 组件的内容字符限制长度，避免内容过长，所以截取了内容字符串，然后补上...。但其实这是个伪需求，即这是给使用者增加了负担，从使用角度来说，增加了一个属性其实也是增加了负担，而仅仅是截取了内容，如果使用者不想补...而是想补......呢？那么是不是还要再加一个属性，来描述补什么？这样会陷入伪需求的循环，并且变得越来越不通用。所以对于非常规的使用，即使用者的特殊的需要，那么就应该提供更通用的允许你自己去解决自己的非常规的场景，那么提供一个插槽是更好的选择。使用者自己去处理字符的超出、补字符或者其他的要求，然后将最终的处理结果使用插槽嵌入组件即可。

技术的成长和对需求的理解即是在类似这样的讨论和教育中才得以提升。而在 code review 的一番解释后，我更改了实现，再次申请 review，最后作者审核通过并合并进源仓库。

5. contributor

到此，一次贡献开源的过程就结束了，而我也成为了一个混子贡献者。但最后在 varlet 的 contributor 中看到自己账号，也不免开始有些🐔你太美。

后记

入群后没多久，varlet 就有一次同城的成员线下聚会，那一次我也参加了，大概七八个人一块吃了自助，成员很多都是以前就认识的，我感慨于他们的相处的轻松氛围也惊叹于他们的技术和经历。

聚会后，耗子君问我愿不愿意加入 varlet 的核心团队，后面一起维护仓库，多贡献代码，我当然是十分乐意。在空闲的时候，贡献自己菜菜的技术，看着仓库变得更大更壮，是非常有成就感的事。所以后面也陆续又提了几次 PR，当然也还都是很小的贡献，但山不嫌卵石、海不厌滴水，功成不必在我，永远不要觉得自己能力不足而畏惧做什么，只要你开始做，则功成必定有你。

最后，还是鼓励大家积极参与开源学习代码、贡献代码，无论你是跟我一样还很菜还是已经是大佬，祝大家 happy coding～👏

指引