TypeScript – 工程层面的类型能力:类型声明、类型指令与命名空间

TypeScript 全面进阶指南专栏目录总览

我们已经结束了 TypeScript 类型能力的学习,这一节将进入 TypeScript 的实战应用篇。实战篇主要包括了工程能力、框架集成、ECMAScript 语法、TSConfig 解析以及 Node API 开发这五个部分。

在这一节,我们主要介绍 TypeScript 的工程能力基础,包括类型指令、类型声明、命名空间这么几个部分。这些概念不仅可以帮助你了解到 TypeScript 工程能力的核心理念,也是接下来实战篇内容的前置基础。

要开始学习工程能力,其实我们可以从一个很简单的场景开始。如果你已经有一定 TypeScript 的使用经验,那你很有可能遇到过这么一个场景:出现了莫名其妙的类型报错,但你又不知道从何入手解决,想让 TypeScript 直接忽略掉这一行出错的代码?此时,类型指令就是你最需要的工具。

本节代码见:Declaration

类型检查指令

在前端世界的许多工具中,其实都提供了 行内注释(Inline Comments) 的能力,用于支持在某一处特定代码使用特殊的配置来覆盖掉全局配置。最常见的即是 ESLint 与 Prettier 提供的禁用检查能力,如 /* eslint-disable-next-lint */<!-- prettier-ignore --> 等。TypeScript 中同样提供了数个行内注释(这里我们称为类型指令),来进行单行代码或单文件级别的配置能力。这些指令均以 // @ts- 开头 ,我们依次来介绍。

ts-ignore 与 ts-expect-error

ts-ignore 应该是使用最为广泛的一个类型指令了,它的作用就是直接禁用掉对下一行代码的类型检查:

// @ts-ignore
const name: string = 599;

基本上所有的类型报错都可以通过这个指令来解决,但由于它本质是上 ignore 而不是 disable,也就意味着如果下一行代码并没有问题,那使用 ignore 反而就是一个错误了。因此 TypeScript 随后又引入了一个更严格版本的 ignore,即 ts-expect-error,它只有在下一行代码真的存在错误时才能被使用,否则它会给出一个错误:

// @ts-expect-error
const name: string = 599;

// @ts-expect-error 错误使用此指令,报错
const age: number = 599;

在这里第二个 expect-error 指令会给出一个报错:无意义的 expect-error 指令

那这两个功能相同的指令应该如何取舍?我的建议是在所有地方都不要使用 ts-ignore,直接把这个指令打入冷宫封存起来。原因在上面我们也说了,对于这类 ignore 指令,本来就应当确保下一行真的存在错误时才去使用。

这两个指令只能对单行代码生效,但如果我们有非常多的类型报错要处理(比如正在将一个 JavaScript 文件迁移到 TypeScript),难道要一个个为所有报错的地方都添加上禁用检查指令?当然不,正如 ESLint 中可以使用 /* eslint-disable-next-line */ 禁用下一行代码检查,也可以使用 /* eslint-disable */ 禁用整个文件检查一样, TypeScript 中也提供了对整个文件生效的类型指令:ts-check 与 ts-nocheck

ts-check 与 ts-nocheck

我们首先来看 ts-nocheck ,你可以把它理解为一个作用于整个文件的 ignore 指令,使用了 ts-nocheck 指令的 TS 文件将不再接受类型检查:

// @ts-nocheck 以下代码均不会抛出错误
const name: string = 599;
const age: number = 'linbudu';

那么 ts-check 呢?这看起来是一个多余的指令,因为默认情况下 TS 文件不是就会被检查吗?实际上,这两个指令还可以用在 JS 文件中。要明白这一点,首先我们要知道,TypeScript 并不是只能检查 TS 文件,对于 JS 文件它也可以通过类型推导与 JSDoc 的方式进行不完全的类型检查。

// JavaScript 文件
let myAge = 18;

// 使用 JSDoc 标注变量类型
/** @type {string} */
let myName;

class Foo {
  prop = 599;
}

在上面的代码中,声明了初始值的 myAge 与 Foo.prop 都能被推导出其类型,而无初始值的 myName 也可以通过 JSDoc 标注的方式来显式地标注类型。

但我们知道 JavaScript 是弱类型语言,表现之一即是变量可以被赋值为与初始值类型不一致的值,比如上面的例子进一步改写:

let myAge = 18;
myAge = "90"; // 与初始值类型不同

/** @type {string} */
let myName;
myName = 599; // 与 JSDoc 标注类型不同

我们的赋值操作在类型层面显然是不成立的,但我们是在 JavaScript 文件中,因此这里并不会有类型报错。如果希望在 JS 文件中也能享受到类型检查,此时 ts-check 指令就可以登场了:

// @ts-check
/** @type {string} */
const myName = 599; // 报错!

let myAge = 18;
myAge = '200'; // 报错!

这里我们的 ts-check 指令为 JavaScript 文件也带来了类型检查,而我们同时还可以使用 ts-expect-error 指令来忽略掉单行的代码检查:

// @ts-check
/** @type {string} */
// @ts-expect-error
const myName = 599; // OK

let myAge = 18;
// @ts-expect-error
myAge = '200'; // OK

而 ts-nocheck 在 JS 文件中的作用和 TS 文件其实也一致,即禁用掉对当前文件的检查。如果我们希望开启对所有 JavaScript 文件的检查,只是忽略掉其中少数呢?此时我们在 TSConfig 中启用 checkJs 配置,来开启对所有包含的 JS 文件的类型检查,然后使用 ts-nocheck 来忽略掉其中少数的 JS 文件。

除了类型指令以外,在实际项目开发中还有一个你会经常打交道的概念:类型声明。

类型声明

在此前我们其实就已经接触到了类型声明,它实际上就是 declare 语法:

declare var f1: () => void;

declare interface Foo {
  prop: string;
}

declare function foo(input: Foo): Foo;

declare class Foo {}

我们可以直接访问这些声明:

declare let otherProp: Foo['prop'];

但不能为这些声明变量赋值:

// × 不允许在环境上下文中使用初始值
declare let result = foo();

// √ Foo
declare let result: ReturnType<typeof foo>;

这些类型声明就像我们在 TypeScript 中的类型标注一样,会存放着特定的类型信息,同时由于它们并不具有实际逻辑,我们可以很方便地使用类型声明来进行类型兼容性的比较、工具类型的声明与测试等等。

除了手动书写这些声明文件,更常见的情况是你的 TypeScript 代码在编译后生成声明文件:

// 源代码
const handler = (input: string): boolean => {
  return input.length > 5;
}

interface Foo {
  name: string;
  age: number;
}

const foo: Foo = {
  name: "林不渡",
  age: 18
}

class FooCls {
  prop!: string;
}

这段代码在编译后会生成一个 .js 文件和一个 .d.ts 文件,而后者即是类型声明文件:

// 生成的类型定义
declare const handler: (input: string) => boolean;

interface Foo {
    name: string;
    age: number;
}

declare const foo: Foo;

declare class FooCls {
    prop: string;
}

这样一来,如果别的文件或是别的项目导入了这段代码,它们就能够从这些类型声明获得对应部分的类型,这也是类型声明的核心作用:将类型独立于 .js 文件进行存储。别人在使用你的代码时,就能够获得这些额外的类型信息。同时,如果你在使用别人没有携带类型声明的 .js 文件,也可以通过类型声明进行类型补全,我们在后面还会了解更多。

接下来,我们要学习如何通过 TypeScript 类型声明的能力,让项目中的类型覆盖更加完整。

让类型定义全面覆盖你的项目

在开始学习下面的内容前,不妨先想想你是否遇到过这么几个场景?

  • 想要使用一个 npm 包,但它发布的时间太早,根本没有携带类型定义,于是你的项目里就出现了这么一处没有被类型覆盖的地方。
  • 你想要在代码里导入一些非代码文件,反正 Webpack 会帮你处理,但是可恶的 TS 又报错了?
  • 这个项目在运行时动态注入了一些全局变量(如 window.errorReporter),你想要在代码里直接这样访问,却发现类型又报错了…

这些问题都可以通过类型声明来解决,这也是它的核心能力:通过额外的类型声明文件,在核心代码文件以外去提供对类型的进一步补全。类型声明文件,即 .d.ts 结尾的文件,它会自动地被 TS 加载到环境中,实现对应部分代码的类型补全。

声明文件中并不包含实际的代码逻辑,它做的事只有一件:为 TypeScript 类型检查与推导提供额外的类型信息,而使用的语法仍然是 TypeScript 的 declare 关键字,只不过现在我们要进一步学习其它打开方式了。

要详细学习声明文件与 declare 关键字,我们不妨先来看看如何解决上面的问题。首先是无类型定义的 npm 包,我们可以通过 declare module 的方式来提供其类型:

import foo from 'pkg';

const res = foo.handler();

这里的 pkg 是一个没有类型定义的 npm 包(实际并不存在),我们来看如何为它添加类型提示。

declare module 'pkg' {
  const handler: () => boolean;
}

现在我们的 res 就具有了 boolean 类型!declare module 'pkg' 会为默认导入 foo 添加一个具有 handler 的类型,虽然这里的 pkg 根本不存在。我们也可以在 declare module 中使用默认导出:

declare module 'pkg2' {
  const handler: () => boolean;
  export default handler;
}

import bar from 'pkg2';

bar();

在 'pkg' 的类型声明中,你也可以使用 export const ,效果是一致的,但由于对 'pkg2' 我们使用了默认导入,因此必须要有一个 export default

除了为缺失类型的模块声明类型以外,使用类型声明我们还可以为非代码文件,如图片、CSS文件等声明类型。

对于非代码文件,比如说 markdown 文件,假设我们希望导入一个 .md 文件,由于其本质和 npm 包一样是一条导入语句,因此我们可以类似地使用 declare module 语法:

// index.ts
import raw from './note.md';

const content = raw.replace('NOTE', `NOTE${new Date().getDay()}`);

// declare.d.ts
declare module '*.md' {
  const raw: string;
  export default raw;
}

对于非代码文件的导入,更常见的其实是 .css.module.css.png 这一类,但基本语法都相似,我们在后面还会见到更多。

总结一下,declare module 通常用于为没有提供类型定义的库进行类型的补全,以及为非代码文件提供基本类型定义。但在实际使用中,如果一个库没有内置类型定义,TypeScript 也会提示你,是否要安装 @types/xxx 这样的包。那这个包又是什么?

DefinitelyTyped

简单来说,@types/ 开头的这一类 npm 包均属于 DefinitelyTyped ,它是 TypeScript 维护的,专用于为社区存在的无类型定义的 JavaScript 库添加类型支持,常见的有 @types/react @types/lodash 等等。通过 DefinitelyTyped 来提供类型定义的包常见的有几种情况,如 Lodash 这样的库仍然有大量 JavaScript 项目使用,将类型定义内置在里面不一定是所有人都需要的,反而会影响包的体积。还有像 React 这种不是用纯 JavaScript / TypeScript 书写的库,需要自己来手写类型声明(React 是用 Flow 写的,这是一门同样为 JavaScript 添加类型的语言,或者说语法)。

举例来说,只要你安装了 @types/react,TypeScript 会自动将其加载到环境中(实际上所有 @types/ 下的包都会自动被加载),并作为 react 模块内部 API 的声明。但这些类型定义并不一定都是通过 declare module,我们下面介绍的命名空间 namespace 其实也可以实现一样的能力。

先来看 @types/node 中与 @types/react 中分别是如何进行类型声明的:

// @types/node
declare module 'fs' { 
    export function readFileSync(/** 省略 */): Buffer;
}

// @types/react
declare namespace React {
    function useState<S>(): [S, Dispatch<SetStateAction<S>>];
}

可以看到,@types/node 中仍然使用 declare module 的方式为 fs 这个内置模块声明了类型,而 @types/react 则使用的是我们没见过的 declare namespace 。别担心,我们会在后面详细介绍。

回到上面的最后一个问题,如果第三方库并不是通过导出来使用,而是直接在全局注入了变量,如 CDN 引入与某些监控埋点 SDK 的引入,我们需要通过 window.xxx 的方式访问,而类型声明很显然并不存在。此时我们仍然可以通过类型声明,但不再是通过 declare module 了。

扩展已有的类型定义

对全局变量的声明,还是以 window 为例,实际上我们如果 Ctrl + 点击代码中的 window,会发现它已经有类型声明了:

declare var window: Window & typeof globalThis;

interface Window {
  // ...
}

这行代码来自于 lib.dom.d.ts 文件,它定义了对浏览器文档对象模型的类型声明,这就是 TypeScript 提供的内置类型,也是“出厂自带”的类型检查能力的依据。类似的,还有内置的 lib.es2021.d.ts 这种文件定义了对 ECMAScript 每个版本的类型声明新增或改动等等。

我们要做的,实际上就是在内置类型声明的基础之上,再新增一部分属性。而别忘了,在 JavaScript 中当你访问全局变量时,是可以直接忽略 window 的:

onerror = () => {};

反过来,在类型声明中,如果我们直接声明一个变量,那就相当于将它声明在了全局空间中:

// 类型声明
declare const errorReporter: (err: any) => void;

// 实际使用
errorReporter("err!");

而如果我们就是想将它显式的添加到已有的 Window 接口中呢?在接口一节中我们其实已经了解到,如果你有多个同名接口,那么这些接口实际上是会被合并的,这一特性在类型声明中也是如此。因此,我们再声明一个 Window 接口即可:

interface Window {
  userTracker: (...args: any[]) => Promise<void>;
}

window.userTracker("click!")

类似的,我们也可以扩展来自 @types/ 包的类型定义:

declare module 'fs' {
  export function bump(): void;
}

import { bump } from 'fs';

总结一下这两个部分,TypeScript 通过 DefinitelyTyped ,也就是 @types/ 系列的 npm 包来为无类型定义的 JavaScript npm 包提供类型支持,这些类型定义 的 npm 包内部其实就是数个 .d.ts 这样的声明文件。

而这些声明文件主要通过 declare / namespace 的语法进行类型的描述,我们可以通过项目内额外的声明文件,来实现为非代码文件的导入,或者是全局变量添加上类型声明。而对于多个类型声明文件,如果我们想复用某一个已定义的类型呢?此时三斜线指令就该登场了。

三斜线指令

三斜线指令就像是声明文件中的导入语句一样,它的作用就是声明当前的文件依赖的其他类型声明。而这里的“其他类型声明”包括了 TS 内置类型声明(lib.d.ts)、三方库的类型声明以及你自己提供的类型声明文件等。

三斜线指令本质上就是一个自闭合的 XML 标签,其语法大致如下:

/// <reference path="./other.d.ts" />
/// <reference types="node" />
/// <reference lib="dom" />

需要注意的是,三斜线指令必须被放置在文件的顶部才能生效

这里的三条指令作用其实都是声明当前文件依赖的外部类型声明,只不过使用的方式不同:分别使用了 path、types、lib 这三个不同属性,我们来依次解析。

使用 path 的 reference 指令,其 path 属性的值为一个相对路径,指向你项目内的其他声明文件。而在编译时,TS 会沿着 path 指定的路径不断深入寻找,最深的那个没有其他依赖的声明文件会被最先加载。

// @types/node 中的示例
/// <reference path="fs.d.ts" />

使用 types 的 reference 指令,其 types 的值是一个包名,也就是你想引入的 @types/ 声明,如上面的例子中我们实际上是在声明当前文件对 @types/node 的依赖。而如果你的代码文件(.ts)中声明了对某一个包的类型导入,那么在编译产生的声明文件(.d.ts)中会自动包含引用它的指令。

/// <reference types="node" />

使用 lib 的 reference 指令类似于 types,只不过这里 lib 导入的是 TypeScript 内置的类型声明,如下面的例子我们声明了对 lib.dom.d.ts 的依赖:

// vite/client.d.ts
/// <reference lib="dom" />

而如果我们使用 /// <reference lib="esnext.promise" />,那么将依赖的就是 lib.esnext.promise.d.ts 文件。

这三种指令的目的都是引入当前文件所依赖的其他类型声明,只不过适用场景不同而已。

如果说三斜线指令的作用就像导入语句一样,那么命名空间(namespace)就像一个模块文件一样,将一组强相关的逻辑收拢到一个命名空间内部。

命名空间

假设一个场景,我们的项目里需要接入多个平台的支付 SDK,最开始只有微信支付和支付宝:

class WeChatPaySDK {}

class ALiPaySDK {}

然后又多了美团支付、虚拟货币支付(比如 Q 币)、信用卡支付等等:

class WeChatPaySDK {}

class ALiPaySDK {}

class MeiTuanPaySDK {}

class CreditCardPaySDK {}

class QQCoinPaySDK {}

随着业务的不断发展,项目中可能需要引入越来越多的支付 SDK,甚至还有比特币和以太坊,此时将这些所有的支付都放在一个文件内未免过于杂乱了。这些支付方式其实大致可以分成两种:现实货币与虚拟货币。此时我们就可以使用命名空间来区分这两类 SDK:

export namespace RealCurrency {
  export class WeChatPaySDK {}

  export class ALiPaySDK {}

  export class MeiTuanPaySDK {}

  export class CreditCardPaySDK {}
}

export namespace VirtualCurrency {
  export class QQCoinPaySDK {}

  export class BitCoinPaySDK {}

  export class ETHPaySDK {}
}

注意,这里的代码是在 .ts 文件中的,此时它是具有实际逻辑意义的,也不能和类型混作一谈。

而命名空间的使用类似于枚举:

const weChatPaySDK = new RealCurrency.WeChatPaySDK();

唯一需要注意的是,命名空间内部实际上就像是一个独立的代码文件,因此其中的变量需要导出以后,才能通过 RealCurrency.WeChatPaySDK 这样的形式访问。

如果你开始学习前端的时间较早,一定会觉得命名空间的编译产物很眼熟——它就像是上古时期里使用的伪模块化方案:

export var RealCurrency;
(function (RealCurrency) {
    class WeChatPaySDK {
    }
    RealCurrency.WeChatPaySDK = WeChatPaySDK;
    class ALiPaySDK {
    }
    RealCurrency.ALiPaySDK = ALiPaySDK;
    class MeiTuanPaySDK {
    }
    RealCurrency.MeiTuanPaySDK = MeiTuanPaySDK;
    class CreditCardPaySDK {
    }
    RealCurrency.CreditCardPaySDK = CreditCardPaySDK;
})(RealCurrency || (RealCurrency = {}));

实际上,命名空间的作用也正是实现简单的模块化功能,在 TypeScript 中引入它时(1.5 版本),前端的模块化方案还处于混沌时期。

命名空间的内部还可以再嵌套命名空间,比如在虚拟货币中再新增区块链货币一类,此时嵌套的命名空间也需要被导出:

export namespace VirtualCurrency {
  export class QQCoinPaySDK {}

  export namespace BlockChainCurrency {
    export class BitCoinPaySDK {}

    export class ETHPaySDK {}
  }
}

const ethPaySDK = new VirtualCurrency.BlockChainCurrency.ETHPaySDK();

类似于类型声明中的同名接口合并,命名空间也可以进行合并,但需要通过三斜线指令来声明导入。

// animal.ts
namespace Animal {
  export namespace ProtectedAnimals {}
}

// dog.ts
/// <reference path="animal.ts" />
namespace Animal {
  export namespace Dog {
    export function bark() {}
  }
}

// corgi.ts
/// <reference path="dog.ts" />
namespace Animal {
  export namespace Dog {
    export namespace Corgi {
      export function corgiBark() {}
    }
  }
}

实际使用时需要导入全部的依赖文件:

/// <reference path="animal.ts" />
/// <reference path="dog.ts" />
/// <reference path="corgi.ts" />

Animal.Dog.Corgi.corgiBark();

除了在 .ts 文件中使用以外,命名空间也可以在声明文件中使用,即 declare namespace

declare namespace Animal {
  export interface Dog {}

  export interface Cat {}
}

declare let dog: Animal.Dog;
declare let cat: Animal.Cat;

但如果你在 @types/ 系列的包下,想要通过 namespace 进行模块的声明,还需要注意将其导出,然后才会加载到对应的模块下。以 @types/react 为例:

export = React;
export as namespace React;
declare namespace React {
  // 省略了不必要的类型标注
  function useState<S>(initialState): [];
}

首先我们声明了一个命名空间 React,然后使用 export = React 将它导出了,这样我们就能够在从 react 中导入方法时,获得命名空间内部的类型声明,如 useState。

从这一个角度来看,declare namespace 其实就类似于普通的 declare 语法,只是内部的类型我们不再需要使用 declare 关键字(比如我们直接在 namespace 内部 function useState(): [] 即可)。

而还有一行 export as namespace React ,它的作用是在启用了 --allowUmdGlobalAccess 配置的情况下,允许将这个模块作为全局变量使用(也就是不导入直接使用),这一特性同样也适用于通过 CDN 资源导入模块时的变量类型声明。

除了这两处 namespace 使用,React 中还利用 namespace 合并的特性,在全局的命名空间中注入了一些类型:

declare global {
  namespace JSX {
    interface Element extends React.ReactElement<any, any> { }
  }
}

这也是为什么我们可以在全局使用 JSX.Element 作为类型标注。

除了类型声明中的导入——三斜线指令,以及类型声明中的模块——命名空间以外,TypeScript 还允许你将这些类型去导入到代码文件中。

仅类型导入

在 TypeScript 中,当我们导入一个类型时其实并不需要额外的操作,和导入一个实际值是完全一样的:

// foo.ts
export const Foo = () => {};

export type FooType = any;

// index.ts
import { Foo, FooType } from "./foo";

虽然类型导入和值导入存在于同一条导入语句中,在编译后的 JS 代码里还是只会有值导入存在,同时在编译的过程中,值与类型所在的内存空间也是分开的。

在这里我们只能通过名称来区分值和类型,但为每一个类型都加一个 Type 后缀也太奇怪了。实际上,我们可以更好地区分值导入和类型导入,只需要通过 import type 语法即可:

import { Foo } from "./foo";
import type { FooType } from "./foo";

这样会造成导入语句数量激增,如果你想同时保持较少的导入语句数量又想区分值和类型导入,也可以使用同一导入语句内的方式(需要 4.6 版本以后才支持):

import { Foo, type FooType } from "./foo";

这实际上是我个人编码习惯的一部分,即对导入语句块的规范整理。在大型项目中一个文件顶部有几十条导入语句是非常常见的,它们可能来自第三方库、UI库、项目内工具方法、样式文件、类型,项目内工具方法可能又分成 constants、hooks、utils、config 等等。如果将这些所有类型的导入都混乱地堆放在一起,对于后续的维护无疑是灾难。因此,我通常会将这些导入按照实际意义进行组织,顺序大致是这样:

  • 一般最上面会是 React;
  • 第三方 UI 组件,然后是项目内封装的其他组件;
  • 第三方工具库,然后是项目内封装的工具方法,具体 hooks 和 utils 等分类的顺序可以按照自己偏好来;
  • 类型导入,包括第三方库的类型导入、项目内的类型导入等;
  • 样式文件,CSS-IN-JS 方案的组件应该被放在第二条中其他组件部分。

示例如下:

import { useEffect } from 'react';

import { Button, Dialog } from 'ui';
import { ChildComp } from './child';

import { store } from '@/store'
import { useCookie } from '@/hooks/useCookie';
import { SOME_CONSTANTS } from '@/utils/constants';

import type { FC } from 'react';
import type { Foo } from '@/typings/foo';
import type { Shared } from '@/typings/shared';

import styles from './index.module.scss';

总结与预告

在这一节,我们主要了解了 TypeScript 在工程层面的基础能力,包括类型指令类型声明命名空间三个部分。

类型声明相关的能力几乎是所有规模的工程都会使用到的(你总会遇到没有提供类型定义的库吧),通过大量的额外类型声明我们可以实现更复杂、更准确的类型保护,以及为上古时期的 JavaScript npm 包提供类型定义,即 DefinitelyTyped。但类型指令却相反,它绝对不应该被滥用,无论是相当于后门的 ts-ignore 还是稍显安全的 ts-expect-error 。我们会在后面介绍如何通过 ESLint 规则来进行对应地约束。

而三斜线指令与命名空间这两个概念,虽然已经不再被大量使用,但了解它们诞生与存在的意义同样对理解整个 TypeScript 工程能力很有帮助。在下一节,我们还会与三斜线指令再次碰面。

无论你是在将 TypeScript 集成到什么框架或者工具里,其实你在做的只是一件事,那就是类型,类型,类型!。包括我们在下一节所要学习的 React 与 TypeScript 结合实战,其实本质上也是在学习如何让你的 React 组件也拥有可靠的类型支持。

扩展阅读

通过 JSDoc 在 JS 文件中获得类型提示

在上面我们提到了可以在 JS 文件中通过 JSDoc 来标注变量类型,而既然有了类型标注,那么自然也能享受到像 TS 文件中一样的类型提示了。但这里我们需要使用更强大一些的 JSDoc 能力:在 @type {} 中使用导入语句!

以拥有海量配置项的 Webpack 为例:

/** @type {import("webpack").Configuration} */
const config = {};

module.exports = config;

此时你会发现已经拥有了如臂使指的类型提示:

工程层面的类型能力:类型声明、类型指令与命名空间

类似的,也可以直接进行导出:

module.exports = /** @type { import('webpack').Configuration } */ ({});

当然,Webpack 本身也支持通过 ts 文件进行配置,在使用 TS 进行配置时,一种方式是简单地使用它提供的类型作为一个对象的标注。而目前更常见的一种方式其实是框架内部提供 defineConfig 这样的方法,让你能直接获得类型提示,如 Vite 中的做法:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()]
})
免责声明:
1.本站所有内容由本站原创、网络转载、消息撰写、网友投稿等几部分组成。
2.本站原创文字内容若未经特别声明,则遵循协议CC3.0共享协议,转载请务必注明原文链接。
3.本站部分来源于网络转载的文章信息是出于传递更多信息之目的,不意味着赞同其观点。
4.本站所有源码与软件均为原作者提供,仅供学习和研究使用。
5.如您对本网站的相关版权有任何异议,或者认为侵犯了您的合法权益,请及时通知我们处理。
火焰兔 » TypeScript – 工程层面的类型能力:类型声明、类型指令与命名空间