大家好，我是若川。最近組織了源碼共讀活動，感興趣的可以點此加我微信 ruochuan12?參與，每周大家一起學習200行左右的源碼，共同進步。同時極力推薦訂閱我寫的《學習源碼整體架構系列》?包含20余篇源碼文章。

這篇文章在知乎被尤雨溪點贊了。不過作者不是我（若川）。以下是正文：

---

前言

本文主要分享過去一年自己給Vue社區(qū)生態(tài)貢獻代碼的經歷。

希望自己的經歷能給予想嘗試/了解如何參與開源貢獻的朋友們幫助和參考。

團隊的力量

在開始介紹經歷之前，我想先跟大家聊聊我對開源貢獻的看法。

一個開源項目能火起來的原因可能有很多種,比如解決了某個痛點,提升了某種效率.

但是要活下來卻是一定離不開持續(xù)維護與迭代,持續(xù)不斷地為你的用戶、下游解決問題和痛點。舉個 🌰:

假設我們開源了某個UI庫 (基于Vue2),獲得了很多用戶的喜愛. 而后,Vue2隨著發(fā)展發(fā)布了Vue3,但是我們因為種種原因 (忙著網戀、卷不動了、不愛了)沒有兼容Vue3,開始無法滿足一些用戶的需求,導致用戶流失,那其實這個庫離退休也不遠了(用過一些KPI產物的我們懂的都懂).

一個人的精力是有限的,一個項目要走的更遠需要很多優(yōu)秀開源者的參與和貢獻。就拿Vite舉例吧,在有人還在調研它適不適合上生產的時候,其實它已經擁有了不錯的生態(tài)系統(tǒng):?

Vite核心團隊成員patak寫了一篇關于Vite生態(tài)系統(tǒng)的介紹,其中也感謝了很多大佬的貢獻,所以說一個好的項目離不開大家的貢獻～

貢獻經歷

關于我的貢獻經歷我簡單總結為三個階段,貢獻的PR比較零散與瑣碎,所以每個階段我只挑選一個相對具備代表性的進行分享～

錯別字殺手 (Typo Killer)

故事要從那個炎熱的夏天說起,我在調研?vuejs/composition-api的時候在官方文檔中發(fā)現(xiàn)了文檔格式錯誤,眼里容不得沙子的我 "Fork -> Fixed -> PR " 三連,開啟了我尊貴的Vue Contributor (混PR)生涯。

為什么我把這個階段稱為"錯別字殺手"呢 ?
從上面這個PR我們可以看出,給開源項目貢獻代碼其實不難,甚至可以說很簡單.也正是因為這樣,我們很容易迷失,為了功利心去參與,"為了貢獻而貢獻".這很明顯是錯誤的,我們需要端正好心態(tài)。

就這樣,我開始了開源貢獻的第一步。

問題修復 (Issue Fixed)

大家都知道Vue3有一個script setup語法糖,經過幾個月的提案也終于在V3.2定稿,V3.2發(fā)布后我也在觀察它的穩(wěn)定情況,是否能應用到生產.在觀察的過程中,我在issue中看到了一個Bug Report:??這個Bug的意思是說defineProps語法生成了不正確的PropType.當時我就在想,是不是在編譯script setup語法的時候沒有正確處理導致的呢 ? 心里也冒出了一個想法:(確認問題并修復它),但是這時心里又有另一個小惡魔在說:(不行啊,你沒有熟讀精通Vue源碼 逃:) ). 一心想貢獻代碼 (混PR)的我當然不會放過這次機會了~

如何Debug ?

要確認問題之前我們必須要懂得如何debug代碼,不能純粹靠愛和意念發(fā)電,這里我分享下我的思路 (或許有更好的辦法),通過測試用例來調試:

• 打開?Jest(Vue3單測工具)配置文件,將testMatch配置改成你要調試的對應文件

• 注釋掉所有測試用例并編寫測試用例 (這里的用例就是上圖應用場景)

• OK,現(xiàn)在你只要找到相關的代碼位置 (Vue3采用Mono Repo目錄結構,查找相關功能函數(shù)還是蠻容易的) 就能進行斷點或者打印調試了,并根據(jù)測試用例斷言驗證你的修復成果.

測試用例

給一些集成了自動化測試工具的項目提PR,必須帶上相應的測試用例:

• 保證你的PR能被快速驗證

• 提升代碼覆蓋率與代碼健壯性

功能新增 (Feature Request)

大家都知道Vue3引入了Composition API,用于提升邏輯復用能力. 這里要提到的是vueuse,它提供了很多易用且應用場景高頻的hook,比如?useLocalStorage,useDebounce等.

我在做需求時,有一個滾動功能需要實現(xiàn),我發(fā)現(xiàn)vueuse并沒有提供對應的hook,我認為這個功能是通用并且高頻的,如果能將它實現(xiàn)并集成到vueuse那就太酷了.于是我閱讀了貢獻指南,開始了我的useScroll實現(xiàn):

1. 新建issue確認可行性

2. 功能設計

3. 功能實現(xiàn)

不是本文重點,就不貼代碼了,有興趣的👇

4. 提交PR

使用反饋

看到自己實現(xiàn)的功能有人使用并提交PR補充特性,還是蠻開心的 😛

Project Activity

雖然沒啥含金量,還是發(fā)出來裝下~逃 :)?

貢獻指北

在這里,我分享幾個給開源項目貢獻代碼的注意事項:

用英語交流

?有的人可能會有疑問,作者明明是中國人,為什么要用英語呢 ? 這里拿Vue舉例說說我的看法 :

• 項目成員來自五湖四海,幫你解決問題的人可能看不懂中文. (畢竟英語是全球通用語言)

• Vue在國內外都有一定的用戶體量,可能有歪果友仁和你遇到一樣的問題或對你的解決方案感興趣,用英語方便大家檢索issue和PR.

有的大佬會說:"不行啊,我不會英語啊". 其實作者也是一名"翻譯選手",有道,谷歌,總有一款翻譯軟件適合你.(說實話,用久了你會發(fā)現(xiàn)你的英語在進步)

?So, 在提issue、PR甚至git commit msg時帶上你的english吧～

遵循官方規(guī)范

正所謂"沒有規(guī)矩不成方圓",為了讓官方可以更清晰、迅速、準確地定位、復現(xiàn)、解決你的問題,請 :

• 提issue時遵循官方模版并準確描述信息.

• 提issue時盡量提供最小可復現(xiàn)demo (mini repo),這里可以是CodeSandbox、Github鏈接等.

• 提PR前先閱讀貢獻指南 (如果有的話).

• 優(yōu)雅的提交你的Git Commit Message,最簡單的辦法就是直接查看你要貢獻倉庫的Commit History,抄它 !

CI/CD流程

?一般開源項目都有一套基于Github Action的CI/CD流程,用于校驗和規(guī)范貢獻者的代碼格式和健壯性等.比較常見的就是自動化lint和自動化測試集成.所以我們在提交PR之前最好先跑一遍這個流程確認沒問題,這個一般在package.json文件的scripts命令就能看到.

這里有個小技巧就是可以在你的commit message里加上?[skip ci],?[ci skip],?[no ci],?[skip actions],[actions skip]等關鍵詞跳過CI,這個常用于修復文檔及錯別字等.

收獲成長

成就感

當我們站在巨人的肩膀上使用開源庫高效為業(yè)務賦能的同時,能盡自己的一份力反哺社區(qū),給到社區(qū)一些正反饋,自己也能收獲成就感.

技術成長

當我們嘗試修復issue和?PR被review的時候,其實在這個過程中我們也在鍛煉自己解決問題及編碼的能力.

結語

最后想在這里感謝一下大佬?Anthony Fu,一名非常厲害的全職開源者.感嘆你在保持多個項目的維護與貢獻時還能產出多個Awesome的項目.從你身上學習和受益了很多 !

關于開源貢獻自己也是一個新手,這篇文章的目的一方面是對自己在這塊的回顧與總結,另一個是希望能給想?yún)⑴c開源的伙伴一個參考.

生命不息,開源不止. 瑞思拜 !

·················?若川簡介?·················

你好，我是若川，畢業(yè)于江西高校。現(xiàn)在是一名前端開發(fā)“工程師”。寫有《學習源碼整體架構系列》20余篇，在知乎、掘金收獲超百萬閱讀。
從2014年起，每年都會寫一篇年度總結，已經寫了7篇，點擊查看年度總結。
同時，最近組織了源碼共讀活動，幫助3000+前端人學會看源碼。公眾號愿景：幫助5年內前端人走向前列。

識別上方二維碼加我微信、拉你進源碼共讀群

今日話題

略。分享、收藏、點贊、在看我的文章就是對我最大的支持～

總結

以上是生活随笔為你收集整理的竟然被尤雨溪点赞了：我给Vue生态贡献代码的这一年的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。