我们看个具体的例子。下面这个使用 TypeScript 编写的 SAP UI5 Component：

import UIComponent from "sap/ui/core/UIComponent";

/**
 * @namespace ui5.typescript.helloworld
 */
export default class Component extends UIComponent {

    public multiply(x : number, y : number) : number {
        return x * y;
    }
}

第一行 import 的 UIComponent，其类型定义从哪里来？

我们如果对着 "sap/ui/core/UIComponent" 单击鼠标左键，就会看到一个 declare module 的声明。

单击之后，在 node_modules 文件夹下的 @types 文件夹的 openui5 下面，能找到一个 sap.ui.core.d.ts 文件：

这就是所谓的 DefinitelyTyped 外部类型定义文件。

UI5 for TypeScript 的外部类型定义文件的安装方式：

npm install --save @types/openui5

地址：https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/openui5

这些外部定义都是从 OpenUI5 JSDoc 生成的。 如果出现问题，需要修复原始 OpenUI5 存储库中的生成器或 JSDoc，而不是此存储库中的定义文件。

OpenUI5 类型定义在两个 npm 包名下发布：

• @openui5/ts-types-esm（由 UI5 开发团队直接发布）
• @types/openui5（通过 DefinitelyTyped 维护的）

二者的差异：

• 对于@openui5/ts-types-esm 上的那些类型定义，每当发布 OpenUI5 的新补丁版本时，都会发布一个新补丁版本。即使类型定义没有变化。这意味着代码和类型定义在使用完全相同的版本时完全同步。

然而，对于 @types/openui5，DefinitelyTyped 采用了definitelyTyped 的版本控制方法：

只有主要和次要版本号在库包和类型声明包之间对齐。
类型声明包的补丁版本与库补丁版本无关。

这背后的原因是，使用语义版本控制，对于相同主要/次要版本的所有补丁版本，API 将保持不变。例如：OpenUI5 1.90.0 和 OpenUI5 1.90.8 之间没有 API 变化。因此，无需为 OpenUI5 1.90.8（以及 1.90.7、1.90.6 等）发布新的类型定义。

唯一的例外是，当文档或定义生成器中存在重大改进或修复时，我们仍可能在 DefinitiveTyped 上创建新的补丁版本。

更多Jerry的原创文章，尽在："汪子熙":