我们看个具体的例子。下面这个使用 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 上创建新的补丁版本。
