最近那个第一次 Pull Request 挺火的，Twitter 哦不对 X 上看到好几个在秀的，正巧昨天我收到了第二个但实际上算第一个 PR，达成了收发 Issue + PR 的成就（GitHub 应该设一个），于是我也要来说一说。

写代码也好多年了，才收到第一个 PR，这到底是好事还是悲哀呢……

我看别人用 firstpr.me 看自己的第一个 Issue 和 Pull Request，但实际上在 GitHub 的左上角菜单里就能查。

发第一个 Issue #

2021 年是前端的一个重要的转折点，以 Vite、SWC 为首的一票工具相继进入大众的视线，让更快的语言抬着 JavaScript 走成为了未来的方向。

我也跟风去用它们，因为比起 Golang 我更喜欢 Rust，所以首先尝试把 SWC 整到我的项目里。

好不容易改完配置，一运行直接报错。顺着 stacktrace 爬过去一看它把

a.b = 1;
a = null;

给优化成了null.b=1。这种优化好像叫常量传播来着，可惜传反了。

无论是编译优化还是 Rust 都不是我擅长的，所以没能发 PR 而是提了一个 Issue。

可能是因为压缩还是实验中的功能，SWC 过了俩月才修，这期间我已经改用 Vite 了。

发第一个 PR #

我发的第一个 PR 并不完美，它是修复一个 BUG，由于忘记处理 AES 加密的填充而导致解析失败的问题。

我当时并没有找到错误的原因，索性直接依靠 XML 结尾标记来删除后面的多余内容，这并不是最好的做法。

还好作者修了我的 PR 后合并了。现在想想，要是第一个 PR 就被拒，会不会对打击我的积极性呢？

收到第一个 Issue #

我收到的第一个 Issue 很遗憾，由于通知设置有点什么问题（现在也想不起来），总之就是没收到邮件，导致我过了一年才看到它。

然后嘛，就没然后了，毕竟都过一年了。这是我博客的后端，我觉得除了我没人会去用的，所以就从来不看 Issues……

这第一个 Issue 也是我注册 GitHub 后的第一次交流，结果却如此失败。

收到第一个 PR #

我收到的第一个 PR很怪，是日常更新依赖的。因为前端变化快，我的所有项目都是定期更新依赖，通常一星期到一个月一次。

第一眼看到 PR 的提醒邮件，我还以 dependbot 升级了呢，不止能更单个的，还能一次给我全更了。

再仔细一看，这 PR 啥内容都没写，分支名里有个 codespace，我推测是有谁在网页编辑器里搞错了什么操作，导致发出了 PR。

过了两天作者自己就关闭了。

最后，这算第一个 PR 吗？显然不算！所谓 PR 指的是那些满怀心意的更改，从这种角度来说，意外提交、以及各种 bot 都不能算。

拔作岛第二部中文版发售了哦

收到第一个 PR（真） #

好的这回是真正的第一次合 PR 了，同样有点怪，因为通常来说 PR 这东西都是使用者给被使用的项目提的，而这个 PR 却不是。

在日常更新依赖中，我发现 tsd-lite 这个库被废弃了，替代者是同一个作者的新项目 TSTyche，于是我就顺便迁移了过去，成为了该项目的第一批使用者。

第二天我就收到了作者的 PR，帮我纠正了用法……

是不是挺少见的，作者为了收集反馈主动给用户改代码，就这股热情我得给他的项目点个⭐Star。

在合并之前，我看到作者问了一些用法上的问题，便交流了一下，可能是我回复的太慢，作者觉得我要拒绝合并？来了句 In any case, this is your repo and you are the boss here. I just wanted to hear some feedback.

其实我那会在检查其它的测试用例，以及搜索如何查找自己的项目被哪些项目用了。

这次的操作确实不太好，我应该先合并再搞别的。做开源不只是写代码，还是与人的交流，我也见过一些因为拒绝合并产生的争吵，程序人心理都挺细腻的，这方面我还得多学呢。