继承基础配置

配置的本质是差异

当你看到一个 tsconfig.json 文件只有几行时，它不是简化，而是继承。

{
  "extends": "./tsconfig.base.json",
  "plugins": [{ "name": "next" }]
}

这个文件说：我继承了基础配置的所有内容，只添加了 Next.js 插件。

extends 字段是继承的起点。它指向另一个配置文件，从那里获取所有设置。当前文件只需要声明自己的差异。

这不是语法糖。这是配置管理的核心思想：每个层次只表达自己的独特性。

为什么分层

配置文件容易膨胀。编译选项、路径映射、类型包含规则——每个项目都需要这些。

如果每个项目都写一遍完整配置，重复就成了负担。修改一个编译选项，需要更新所有项目的配置文件。

继承机制打破重复。基础配置定义通用规则，项目配置只声明特殊需求。

这是关注点分离在配置层面的体现。基础配置关注编译器行为，项目配置关注项目需求。

packages/
  shared/tsconfig.json      → extends ../../tsconfig.base.json
  frontend/tsconfig.json    → extends ../../tsconfig.base.json + React 配置
  backend/tsconfig.json     → extends ../../tsconfig.base.json + Node 配置

Next.js 插件的作用

plugins 字段声明了 TypeScript 插件。插件扩展编译器的能力。

{
  "plugins": [{ "name": "next" }]
}

Next.js 插件做三件事：

类型增强。 Next.js 特有的类型（如 GetServerSideProps、AppProps）需要插件提供。

路径解析。 Next.js 的模块解析规则（如 @/components）需要插件理解。

编译时检查。 Next.js 的约定（如 App Router 的文件命名规则）需要插件验证。

插件不改变 TypeScript 编译器的核心行为。它是编译器的扩展，处理框架特定的类型需求。

参考 runtime-type-contract 了解类型契约如何延续到运行时。

覆盖机制

继承不是不可改变。当前配置可以覆盖基础配置的任何选项。

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "strict": false  // 覆盖基础配置的 strict: true
  }
}

覆盖发生在字段级别。如果基础配置定义了 strict: true，当前配置写 strict: false，最终生效的是 false。

这是继承的灵活性。你可以接受大部分基础设置，只改变少数不适合当前项目的选项。

但覆盖应该谨慎。每次覆盖都是偏离通用规则。偏离过多，配置分层失去意义。

路径解析的特殊性

extends 字段使用相对路径。./tsconfig.base.json 表示当前目录的基础配置。

这意味着继承是目录敏感的。移动项目位置，继承路径可能失效。

Next.js 项目常见的结构：

tsconfig.json           → 项目配置,继承 tsconfig.base.json
tsconfig.base.json      → 基础配置,定义通用规则

或者在 Monorepo 中：

root/
  tsconfig.base.json
  packages/
    app/tsconfig.json   → extends ../../tsconfig.base.json

路径的相对性是继承机制的约束。配置文件的位置决定了继承关系。

编译器如何处理继承

TypeScript 编译器读取配置文件时，递归解析 extends 链。

1. 读取当前配置文件
2. 发现 extends 字段,读取基础配置
3. 合并两个配置,当前配置覆盖基础配置
4. 如果基础配置也有 extends,继续递归

最终得到一个合并后的完整配置。这个过程对开发者透明。你只需要写简洁的当前配置,编译器处理继承细节。

参考 fast-type-checking 了解如何快速验证配置是否正确。

最后

配置继承不是减少行数,而是减少重复。

基础配置定义通用规则。项目配置只声明差异。这是分层的本质。

extends 字段让每个配置文件只表达自己的独特性。其余的,交给继承。

Next.js 插件是项目特定的需求。它不属于基础配置,而是项目配置的差异。

配置管理的目标是清晰。继承让每个层次的职责清晰可见。