前言
本文主要分享過去一年自己給Vue社群生態貢獻程式碼的經歷。
希望自己的經歷能給予想嘗試/瞭解如何參與開源貢獻的朋友們幫助和參考。
團隊的力量
在開始介紹經歷之前，我想先跟大家聊聊我對開源貢獻的看法。
一個開源專案能火起來的原因可能有很多種,比如解決了某個痛點,提升了某種效率.
但是要活下來卻是一定離不開持續維護與迭代,持續不斷地為你的使用者、下游解決問題和痛點。舉個 ?:
假設我們開源了某個UI庫 (基於Vue2),獲得了很多使用者的喜愛. 而後,Vue2隨著發展釋出了Vue3,但是我們因為種種原因 (忙著網戀、卷不動了、不愛了)沒有相容Vue3,開始無法滿足一些使用者的需求,導致使用者流失,那其實這個庫離退休也不遠了(用過一些KPI產物的我們懂的都懂).
一個人的精力是有限的,一個專案要走的更遠需要很多優秀開源者的參與和貢獻。就拿Vite舉例吧,在有人還在調研它適不適合上生產的時候,其實它已經擁有了不錯的生態系統:
Vite核心團隊成員patak寫了一篇關於Vite生態系統的介紹,其中也感謝了很多大佬的貢獻,所以說一個好的專案離不開大家的貢獻～
貢獻經歷
關於我的貢獻經歷我簡單總結為三個階段,貢獻的PR比較零散與瑣碎,所以每個階段我只挑選一個相對具備代表性的進行分享～
錯別字殺手 (Typo Killer)
故事要從那個炎熱的夏天說起,我在調研 vuejs/composition-api的時候在官方文件中發現了文件格式錯誤,眼裡容不得沙子的我 "Fork -> Fixed -> PR " 三連,開啟了我尊貴的Vue Contributor (混PR)生涯。
為什麼我把這個階段稱為"錯別字殺手"呢 ?
從上面這個PR我們可以看出,給開源專案貢獻程式碼其實不難,甚至可以說很簡單.也正是因為這樣,我們很容易迷失,為了功利心去參與,"為了貢獻而貢獻".這很明顯是錯誤的,我們需要端正好心態。
就這樣,我開始了開源貢獻的第一步。
問題修復 (Issue Fixed)
大家都知道Vue3有一個script setup語法糖,經過幾個月的提案也終於在V3.2定稿,V3.2釋出後我也在觀察它的穩定情況,是否能應用到生產.在觀察的過程中,我在issue中看到了一個Bug Report:
這個Bug的意思是說defineProps語法生成了不正確的PropType.當時我就在想,是不是在編譯script setup語法的時候沒有正確處理導致的呢 ? 心裡也冒出了一個想法:(確認問題並修復它),但是這時心裡又有另一個小惡魔在說:(不行啊,你沒有熟讀精通Vue原始碼 逃:) ). 一心想貢獻程式碼 (混PR)的我當然不會放過這次機會了~
如何Debug ?
要確認問題之前我們必須要懂得如何debug程式碼,不能純粹靠愛和意念發電,這裡我分享下我的思路 (或許有更好的辦法),通過測試用例來除錯:
- 開啟
Jest(Vue3單測工具)配置檔案,將testMatch配置改成你要除錯的對應檔案 - 註釋掉所有測試用例並編寫測試用例 (這裡的用例就是上圖應用場景)
- OK,現在你只要找到相關的程式碼位置 (Vue3採用
Mono Repo目錄結構,查詢相關功能函式還是蠻容易的) 就能進行斷點或者列印除錯了,並根據測試用例斷言驗證你的修復成果.
測試用例
給一些整合了自動化測試工具的專案提PR,必須帶上相應的測試用例:
- 保證你的PR能被快速驗證
- 提升程式碼覆蓋率與程式碼健壯性
功能新增 (Feature Request)
大家都知道Vue3引入了Composition API,用於提升邏輯複用能力. 這裡要提到的是vueuse,它提供了很多易用且應用場景高頻的hook,比如 useLocalStorage,useDebounce等.
我在做需求時,有一個滾動功能需要實現,我發現vueuse並沒有提供對應的hook,我認為這個功能是通用並且高頻的,如果能將它實現並整合到vueuse那就太酷了.於是我閱讀了貢獻指南,開始了我的useScroll實現:
1. 新建issue確認可行性
2. 功能設計
3. 功能實現
不是本文重點,就不貼程式碼了,有興趣的?
4. 提交PR
使用反饋
看到自己實現的功能有人使用並提交PR補充特性,還是蠻開心的 ?
Project Activity
雖然沒啥含金量,還是發出來裝下~逃 :)
貢獻指北
在這裡,我分享幾個給開源專案貢獻程式碼的注意事項:
用英語交流
有的人可能會有疑問,作者明明是中國人,為什麼要用英語呢 ? 這裡拿Vue舉例說說我的看法 :
- 專案成員來自五湖四海,幫你解決問題的人可能看不懂中文. (畢竟英語是全球通用語言)
Vue在國內外都有一定的使用者體量,可能有歪果友仁和你遇到一樣的問題或對你的解決方案感興趣,用英語方便大家檢索issue和PR.
有的大佬會說:"不行啊,我不會英語啊". 其實作者也是一名"翻譯選手",有道,谷歌,總有一款翻譯軟體適合你.(說實話,用久了你會發現你的英語在進步)
So, 在提issue、PR甚至git commit msg時帶上你的english吧～
遵循官方規範
正所謂"沒有規矩不成方圓",為了讓官方可以更清晰、迅速、準確地定位、復現、解決你的問題,請 :
- 提
issue時遵循官方模版並準確描述資訊. - 提
issue時儘量提供最小可復現demo (mini repo),這裡可以是CodeSandbox、Github連結等. - 提
PR前先閱讀貢獻指南 (如果有的話). - 優雅的提交你的
Git Commit Message,最簡單的辦法就是直接檢視你要貢獻倉庫的Commit History,抄它 !
CI/CD流程
一般開源專案都有一套基於Github Action的CI/CD流程,用於校驗和規範貢獻者的程式碼格式和健壯性等.比較常見的就是自動化lint和自動化測試整合.所以我們在提交PR之前最好先跑一遍這個流程確認沒問題,這個一般在package.json檔案的scripts命令就能看到.
這裡有個小技巧就是可以在你的commit message里加上 [skip ci], [ci skip], [no ci], [skip actions],[actions skip]等關鍵詞跳過CI,這個常用於修復文件及錯別字等.
收穫成長
成就感
當我們站在巨人的肩膀上使用開源庫高效為業務賦能的同時,能儘自己的一份力反哺社群,給到社群一些正反饋,自己也能收穫成就感.
技術成長
當我們嘗試修復issue和 PR被review的時候,其實在這個過程中我們也在鍛鍊自己解決問題及編碼的能力.
結語
最後想在這裡感謝一下大佬 Anthony Fu,一名非常厲害的全職開源者.感嘆你在保持多個專案的維護與貢獻時還能產出多個Awesome的專案.從你身上學習和受益了很多 !
關於開源貢獻自己也是一個新手,這篇文章的目的一方面是對自己在這塊的回顧與總結,另一個是希望能給想參與開源的夥伴一個參考.
生命不息,開源不止. 瑞思拜 !
如果我的文章有幫助到你,歡迎關注我一起玩耍～