API 提取器 助您构建更优质的 TypeScript 库包。例如，假设您的公司发布了一个名为“awesome-widgets”的 NPM 包，它导出了许多类和接口。随着开发人员开始依赖您的库，您可能会遇到以下问题……

• 意外中断：人们不断报告，他们的代码在“次要”更新后无法编译。为了解决这个问题，您大胆提议，每个 awesome-widgets 的拉取请求必须得到您团队中经验丰富的开发人员的批准。但这被证明是不现实的——没有人有时间查看每个 PR！您真正需要的是一种方法来检测更改 API 合同的 PR，并将其标记以供审查。这将把注意力集中在正确的地方……但如何做到呢？

• 缺少导出：假设 awesome-widgets 包导出一个 API 函数 AwesomeButton.draw()，它需要一个类型为 DrawStyle 的参数，但您忘记导出此枚举。最初看起来一切正常，但当开发人员尝试调用该函数时，他们发现没有办法指定 DrawStyle。如何避免这些疏漏？

• 意外导出：您的 DrawHelper 类本应保持内部，但有一天您意识到它被导出了。当您尝试删除它时，用户抱怨他们正在使用它。将来如何避免这种情况？

• Alpha/Beta 毕业：您希望发布尚未准备好正式发布的新 API 的预览。但是，如果您每次这些定义发生变化时都进行主要的 SemVer 升级，村民们就会拿着火把和干草叉来追你！更好的方法是将某些类/成员指定为 alpha 质量，然后在它们成熟后将其提升为 beta，最后提升为 public。但是如何向您的用户说明这一点？（以及如何检测作用域错误？public 函数永远不应该返回 beta 结果。）

• *.d.ts 卷起：您将库打包成一个漂亮的 *.js捆绑文件 - 那么为什么将您的类型作为 lib/*.d.ts 的混乱树文件，里面充满了私有定义？我们不能将它们合并成一个整洁的 *.d.ts 卷起文件吗？如果您发布内部/beta/public 版本，每个发布类型都应该获得自己的 *.d.ts 文件，并进行适当的修剪。开发人员构建生产项目时不想看到一堆 internal 和 beta 成员出现在他们的 VS Code IntelliSense 中！

• 在线文档：您已经认真地为每个 TypeScript 成员添加了漂亮的 TSDoc 描述。现在您的库已经发布，是时候设置 一个格式优美的 API 参考。使用什么工具？

API 提取器 为所有这些问题提供了一个集成的、专业级的解决方案。它在构建时由您的工具链调用，并利用 TypeScript 编译器引擎来

• 检测项目的导出 API 表面
• 将合同捕获在一个简洁的报告中，旨在简化审查
• 警告常见错误（例如缺少导出、可见性不一致等）
• 根据发布类型生成带修剪的 *.d.ts 卷起文件
• 以便于与您的内容管道集成的可移植格式输出 API 文档

最棒的是，API 提取器 是免费的开源软件。加入社区并创建一个拉取请求！