API 提取器 協助您建構更完善的 TypeScript 程式庫套件。例如，假設您的公司發布了一個名為「awesome-widgets」的 NPM 套件，其中匯出了許多類別和介面。隨著開發人員開始依賴您的程式庫，您可能會遇到以下問題…

• 意外的程式碼錯誤： 人們不斷回報，在進行所謂的「次要」更新後，他們的程式碼無法編譯。為了處理這個問題，您大膽地提議每個 awesome-widgets 拉取請求都必須由您團隊中經驗豐富的開發人員批准。但這證明是不切實際的 -- 沒有人有時間查看每一個拉取請求！您真正需要的是一種方法來偵測更改 API 協定的拉取請求，並將其標記以供審查。這將把注意力集中在正確的地方… 但該怎麼做呢？

• 遺漏的匯出： 假設 awesome-widgets 套件匯出了一個 API 函式 AwesomeButton.draw()，它需要一個 DrawStyle 類型的參數，但您忘記匯出這個列舉。一開始似乎沒問題，但當開發人員嘗試呼叫該函式時，他們發現沒有辦法指定 DrawStyle。如何避免這些疏忽？

• 意外的匯出： 您原本打算將 DrawHelper 類別保留為內部使用，但有一天您發現它被匯出了。當您嘗試移除它時，使用者抱怨他們正在使用它。我們將來如何避免這種情況？

• Alpha/Beta 版本升級： 您想要發布尚未準備好正式推出的新 API 的預覽版本。但是，如果您在每次這些定義演變時都進行主要 SemVer 版本更新，使用者就會帶著火把和乾草叉來找您！更好的方法是將某些類別/成員指定為 alpha 品質，然後隨著它們的成熟將它們提升為 beta，最後提升為 公開。但是如何向您的使用者表明這一點呢？（以及如何偵測範圍錯誤？公開 函式不應返回 beta 結果。）

• *.d.ts 彙總： 您已將程式庫打包成一個漂亮的 *.jsbundle 檔案 – 那麼為什麼要將您的類型宣告發布為雜亂的 lib/*.d.ts檔案樹，其中充滿了私有定義？我們不能將它們合併成一個整齊的 *.d.ts 彙總檔案嗎？如果您發布內部/beta/公開版本，則每個版本類型都應該有自己的 *.d.ts 檔案，並進行適當的修剪。建構生產專案的開發人員不希望在他們的 VS Code IntelliSense 中看到一堆 內部 和 beta 成員！

• 線上文件： 您已使用良好的 TSDoc 描述忠實地註釋了每個 TypeScript 成員。現在您的程式庫已發布，是時候設定 格式良好的 API 參考了。要使用什麼工具？

API 提取器 為所有這些問題提供了一個整合的、專業品質的解決方案。它在建構時由您的工具鏈呼叫，並利用 TypeScript 編譯器引擎來

• 偵測專案的匯出 API 介面
• 以簡潔的報告形式擷取協定，以便於審查
• 警告常見錯誤（例如遺漏的匯出、不一致的能見度等）
• 根據版本類型產生帶有修剪的 *.d.ts 彙總
• 以易於與您的內容管道整合的可攜式格式輸出 API 文件

最重要的是，API 提取器 是免費且開源的。加入社群並建立拉取請求！