DefinitelyTyped 貢獻筆記
前情提要
自己是個 TypeScript 愛用者，深深喜愛它帶來的嚴格型別檢查等功能
然而在 NodeJS 的世界中，大多數套件還是用純 JS 寫成
要能在 JS 的混沌世界中享受到 TS 精準嚴格的檢查功能
就必須歸功於背後默默貢獻定義檔的大眾了！
既然依賴著社群，可想而知定義檔更新速度要追上套件更新速度並不容易
會有許多套件已更新但定義檔未更新，導致我們用到過時 API 的問題發生
因此花點時間閱讀常用套件的文件，並協助更新定義檔
對我來說是茶餘飯後很好的休閒XD
希望能透過這篇文章記錄下我貢獻 DT 的過程以及遭遇的問題
貢獻已有定義檔的套件
通常大部份常用的套件都有前人所貢獻的定義檔了
而我目前協助更新的套件也都屬於這種類型
所以在這邊僅能分享「更新現有套件定義檔」的過程
首先可以參考 DT 官方文件的 Make a pull request 段落
第一步：Fork & Clone
將 DT 專案 Fork 到自己名下並 Clone 至電腦中
接著就能在專案內的 types 資料夾中找到要貢獻的子專案了
然而這個步驟我一直覺得有改善空間
因為僅僅是要貢獻某個子專案就必須 Clone 整個 DT
意味著上百個套件的定義檔都會一起下載，非常佔空間又花時間！
不曉得有沒有別的好方法能簡化這個步驟
第二步：修改定義檔
通常該套件的定義檔會位於專案底下的 types/package-name/index.d.ts
找到並修改程式碼即可
但記得修改的同時，也要一併在檔案的開頭更新版本號並署名作者
這樣當 Pull Request 被合併成功，TS 機器人就會自動根據版號推到 npm 上
版本號的更新似乎沒有一定規則，而我個人是喜歡配合該套件的主版號
例如 koa-webpack 這個套件當時主版號為 5
我就把定義檔的版本號定為 5.x
這樣使用者一看也能很清楚對應的版本
而署名的用意除了告訴大家有誰貢獻這個專案以外
還有個很大的作用就是當有人更新這個定義檔時
共同作者們能夠在 GitHub 上接到即時通知
不僅能一起參與 Code Review，也能讓定義檔社群更活躍茁壯
第三步：Lint & Test
當定義檔修改完畢後，可以藉由 lint 與 test 確保程式碼的品質以及正確性
跑的方式很簡單
只要下 npm run lint <package-name> 與 npm run test 的指令即可
接著測試程式便會自動安裝各版本的 TypeScript 並解析定義檔
如果沒有任何錯誤的話就可以繼續下一步了
第四步：Push & Create Pull Request
將修改並測試完的程式碼 Commit並 Push 至自己的專案內
接著就能在「Pull Requests」的頁籤中新增要求了
新增的同時系統會自動檢查是否能合併
沒問題的話就按下「Create pull request」
Create 完畢即會開啟如同建立 Issue 時的畫面
而我個人的習慣也是將 PR 的標題用以下方式命名：[@types/<package-name>] <description>內容則是按照自動建立的樣板填寫即可
第五步：等待 Reviewer 確認 → 大功告成
建立完 PR 過後就是 Reviewer 以及 TS 團隊的人接手了
順利的話一天過後就能在 npm 下載到自己更新過的定義檔啦！
當時我是在 6/4 號凌晨 4 點所建立 PR 的
到 6/5 號凌晨 5 點 TS 團隊即有人幫忙將 PR 關閉了，非常有效率
小結
短短幾個步驟就能貢獻給許多開發者以及整個 TS 社群，成就+1！
然而還是有許多步驟需要在 GitHub 上操作，等於就被這個平台綁住了
如果有個專屬定義檔的更新步驟以及中心化的管理方式肯定不賴
雖然這樣又會跟開源的概念有所矛盾
但 TS 跟 GitHub 現在都是微軟所擁有了，還有什麼事可以更矛盾呢XD
不過我想所有開發者們最殷切期盼的
應該還是「消滅定義檔，但仍保有嚴格型別檢查」這目標吧！
這又是另一個不可能的任務了…
既然還身在這個混沌時代
希望這篇文能吸引更多像我一樣的無聊人士多多貢獻定義檔了=w=
