TypeScript 深水區：三種類型來源和三種模塊語法

作者：神說要有光 2022-06-20 08:50:16

深入掌握 TypeScript 的話，除了學習類型定義以及類型編程，這三種類型聲明的來源（lib、@types、用戶目錄），以及三種模塊聲明的方式（namespace、module、es module），還有全局類型的聲明（global、reference），也都是要掌握的。

TypeScript 給 JavaScript 添加了一套類型語法，我們聲明變量的時候可以給變量加上類型信息，這樣編譯階段就可以檢查出變量使用的對不對，也就是類型檢查。

給變量添加類型，很自然可以想到時在聲明的時候指定：

比如對象：

interface Person {
    name: string;
    age?: number;
}

const guang: Person = {
    name: 'guang'
}

比如函數：

function add(num1: number, num2: number): number {
    return num1 + num2;
}

這樣當使用它們的時候，比如變量賦值、函數調用，就可以通過類型信息檢查出使用的對不對：

TypeScript 這樣設計類型語法沒啥問題，但是只是這樣還不夠。

我們自己寫的代碼可以這樣聲明類型，但不是我們寫的呢？

比如 JS 引擎提供的 Number、String、Date、RegExp，瀏覽器環境的 HTMLElement、Event 等 api。

這些 api 是執行引擎內置的實現，但我們代碼里會用到它們，也同樣需要檢查使用的對不對，也就是類型檢查。怎么給這些 api 加上類型呢？

TypeScript 類型聲明的三種來源

TypeScript 設計了 declare 的語法，可以單獨聲明變量的類型：

比如對象：

interface Person {
    name: string;
    age?: number;
}

declare const guang: Person;

比如函數：

declare function add(num1: number, num2: number): number;

這樣單獨聲明了類型，使用這些 api 的時候也就能做類型檢查。

像 JS 引擎那些 api，還有瀏覽器提供的 api，這些基本是必用的，而且都有標準的。所以 TypeScript 給內置了它們的類型聲明。

TypeScript 包下有個 lib 目錄，里面有一堆 lib.xx.d.ts 的類型聲明文件，這就是 TS 內置的一些類型聲明。

因為這些只是聲明類型，而沒有具體的 JS 實現，TS 就給單獨設計了一種文件類型，也就是 d.ts， d 是 declare 的意思。

比如 lib.dom.d.ts 里的類型聲明：

因為是 ts 內置的，所以配置一下就可以用了：

tsconfig.json 里配置下 compilerOptions.lib，就可以引入對應的 d.ts 的類型聲明文件。

有的同學可能會說，可是內置的類型聲明也不多呀，只有 dom 和 es 的。

確實，因為 JS 的 api 還有瀏覽器的 api 都是有標準的，那自然可以按照標準來定義類型。其余的環境的 api 可能沒有標準，經常變，那自然就沒法內置了，比如 node。所以 lib 里只有 dom 和 es 的類型聲明。

那 node 環境，還有其他環境里的內置 api 怎么配置類型聲明呢？

node 等環境的 api 因為沒有標準而沒有被 TS 內置，但 TS 同樣也支持了這些環境的類型聲明的配置。

方式是通過 @types/xxx 的包：

TS 會先加載內置的 lib 的類型聲明，然后再去查找 @types 包下的類型聲明。

這樣，其他環境的類型聲明就可以通過這種方式來擴展。

@types 包是在 DefinitelyTyped 這個項目下統一管理的，想創建一個 @types 包的話要去看一下他們的文檔。

一般來說，很快就可以發到 npm 的：

我們知道，TS 內置的那些 lib 是可以配置的，擴展的這些 @types/xx 的包自然也可以配置：

可以指定加載 @types 目錄下的哪些包，還可以修改查找 @types 包的目錄（默認是 node_modules/@types)：

除了給 node 等環境的 api 加上類型聲明外，@types 包還有一種用途，就是給一些 JS 的包加上類型聲明：

如果代碼本身是用 ts 寫的，那編譯的時候就可以開啟 compilerOptions.declaration，來生成 d.ts 文件：

然后在 package.json 里配置 types 來指定 dts 的位置：

這樣就不需要單獨的 @types 包了。

但如果代碼不是用 ts 寫的，那可能既需要單獨寫一個 @types/xxx 的包來聲明 ts 類型，然后在 tsconfig.json 里配置下，加載進來。

比如常用的 vue3 就不需要 @types/vue 包，因為本身是用 ts 寫的，npm 包里也包含了 dts 文件。

但是 react 不是 ts 寫的，是用的 facebook 自己的 flow，自然就需要 @types/react 的包來加上 ts 類型聲明。

至此，ts 內置的 dom 和 es 的類型聲明，其他環境還有一些包的類型聲明我們都知道怎么加載了。

那自己寫的 ts 代碼呢？

這些其實我們經常配置，就是配置下編譯的入口文件，通過 includes 指定一堆，然后通過 excludes 去掉一部分。還可以通過 files 再單獨包含一些：

tsc 在編譯的時候，會分別加載 lib 的，@types 下的，還有 include 和 files 的文件，進行類型檢查。

這就是 ts 類型聲明的三種來源。

現在還有一個問題，有的 api 是全局的，有的 api 是某個模塊的，ts 是怎么聲明全局 api 的類型，怎么聲明模塊內的 api 的類型呢？

全局類型聲明 vs 模塊類型聲明

我們寫的 JS 代碼就是有的 api 是全局的，有的 api 是模塊內的，所以 TS 需要支持這個也很正常。

但 JS 的模塊規范不是一開始就有的，最開始是通過在全局掛一個對象，然后這個對象上再掛一些 api 的方式，也就是命名空間 namespace。

所以 TS 最早支持的模塊化方案自然也就是 namespace：

namespace Guang {
    export interface Person {
        name: string;
        age?: number;
    }

    const name = 'guang';
    const age = 20;

    export const guang: Person = {
        name,
        age
    }
    export function add(a: number, b: number):number {
        return a + b;
    }
}