向微軟官方貢獻 @types 包後引起的思考

塗鴉智能大量優質 HC，歡迎你們加入，須要內推評論區告訴我！css

在前端社區中，TypeScript 差很少是老生常談的主題了。這不只反映了 TypeScript 的流行度，也反映了它的學習上手成本。今天咱們不來探討 TypeScript 自己。而是記錄一下我艱難地發佈一個 @types 包的歷程。前端

a year ago

上圖是我在掘金的第一篇文章優雅地使用 TypeScript 開發 React Native 應用中的一條素質問答。問題就是有些庫不是 TS 寫的，也沒提供類型聲明該怎麼辦。從圖中可見我當時的解決方法都是不可複用且不利他的。但這就是我這一年來處理該問題的常規手段。react

像是 Node 有 NPM，Java 有 Maven，TypeScript 也有它的另外一半，那就是號稱 GitHub review 數量之最的 DefinitelyTyped 項目。git

在 TypeScript 大規模應用以前，社區已經有超過 90% 的頂級 JavaScript 庫，或基於 Flow 編寫的庫（React系）。若是沒有 DefinitelyTyped 項目，這些庫想要提供類型支持，無疑只有徹底重構代碼。這既不現實也不必。github

鑑於 DefinitelyTyped 的做用，咱們說 DefinitelyTyped 讓 TypeScript 再次偉大也不爲過。typescript

DefinitelyTyped 目前是由微軟官方維護的開源項目，參與的方式和 Homebrew 差很少，都是基於 GitHub 的工做流:npm

一、檢查是否已存在同名的包：json

npm info @types/tuya-panel-kit
複製代碼

二、安裝 dts-gen：markdown

npm install -g dts-gen
複製代碼

三、生成新包併發

dts-gen --dt --name tuya-panel-kit --template module
複製代碼

四、格式化代碼

npm run prettier -- --write types/tuya-panel-kit/**/*.ts
複製代碼

這一步務必要執行，由於 DefinitelyTyped 十分嚴格，格式不對過不了 CI。過不了 CI，就只配和機器人對話：

五、dtslint

yarn lint tuya-panel-kit
複製代碼

這一步是最讓人頭大的一步，Definitely 的規則可謂嚴苛，真就對的起它的 SLOGAN：

The repository for high quality TypeScript type definitions

我梳理了一下成功路上的絆腳石：

這是一個流程 BUG，若是你的包依賴了 react，你須要執行 cd types/react && npm install 和 cd ~/.dts/typescript-installs/3.2/ && npm install

二、若是你的包依賴了別的外部庫，須要添加到 microsoft/DefinitelyTyped-tools 項目中，不然 CI 不給過。

三、你的類型聲明可能有不少不符合 dtslint 的標準，我看到有的包是在 tslint.json 中配置禁用掉部分規則，可是我作了嘗試後被人工拒絕了。

而後我嘗試在頂部加入 // tslint:disable:max-line-length 禁用規則，在說明緣由後經過了 Review。就在發稿時，最新 PR 卻由於一個禁用規則，被要求修改：

剛開始時，這種嚴苛漫長的 review 流程着實讓我頭大。但在提過 4 個 PR 都被合併後，我發現 review 的人關心的是你爲何要這麼寫，是否是有什麼不得已的苦衷，是否符合高質量的要求。

在參與 DefinitelyTyped 的協做中，我愈來愈發現規範的重要。如此體量的項目，若是沒有嚴格有效的規範約束，勢必會被開發者拋棄。那咱們來看看 DefinitelyTyped 中是如何約束的：

dtslint ：微軟專門寫的用來檢驗類型聲明文件的工具。正是由於它，我作了大量優化工做。
機器人🤖（dt-mergebot、dt-review-bot、typescript-bot-watchdog）：在你的代碼經過全部規範以前，都是這些機器人在和你交互。你們感興趣的話，以後我會單獨出一篇解析的文章
盡職盡責的維護：雖然有時 review 速度明顯很慢（可能由於國外疫情）。可是這些維護者真的是盡職盡責的 review 你的代碼。機器再厲害也只是一個減小工做量的工具。咱們應該致敬的仍是這些爲社區默默奉獻的人。