仅在TypeScript中用命名空间封装类型是否属于反模式？

API 探路者

2026-8-5

问题

经常有人指出TypeScript中不应使用命名空间，例如TypeScript ESLint规则no-namespace就提示「ES2015模块语法优于命名空间」。我熟知ES模块的概念，且我的TS代码也基于ES模块结构搭建。但在某些场景（如UI组件、复杂事件等）下，我会仅用命名空间来封装类型，以便后续更便捷地导入和使用这些类型。

以下是一个UI组件示例：通过import { Button } from 'xyz'，即可获取Button函数本身，以及Button.Type、Button.Variant、Button.Size等所有类型，我认为这种方式极为便捷。

export { Button };

namespace Button {
  export type Type = 'button' | 'submit' | 'reset';
  export type Variant = 'default' | 'primary' | 'warning' | 'danger';
  export type Size = 'small' | 'medium' | 'large';
}

function Button(props: {
  type?: Button.Type;
  variant?: Button.Variant;
  size?: Button.Size;
  // ... and others ...
}) {
  // not important
}

编辑说明：请将该示例视为组件库的一部分，而非应用代码

请问这种仅用命名空间封装TypeScript类型的做法是否属于反模式？请给出解释。

回答

这种做法不算反模式，反而在组件库这类场景里是合理且实用的类型组织方案，原因如下：

类型与核心API强绑定，降低使用成本
把类型挂载到组件本身（如Button.Type），用户导入核心组件后无需额外导入零散的类型（比如ButtonType、ButtonVariant），减少了导入语句数量，同时让类型的归属关系更清晰，组件库的学习和使用门槛更低。
避免命名冲突
组件库中不同组件很可能出现同名类型（比如Modal.Type和Button.Type），用命名空间将类型绑定到对应组件上，能有效规避命名冲突，不用给类型加冗长的前缀来区分。
符合TypeScript的设计逻辑
TypeScript并未完全废弃命名空间，官方文档明确提到，在ES模块内部可以用命名空间来组织相关代码和类型——尤其是需要将一组关联类型与核心实体（如组件函数）绑定的场景，这种方式比单独导出零散类型更紧凑。

需要注意几个细节：

旧版TypeScript（3.8以下）可能存在命名空间与值（如Button函数）绑定的类型推断问题，但新版TS已修复此类问题。
部分ESLint规则可能误报，你可以针对组件文件单独禁用no-namespace，比如在文件顶部添加/* eslint-disable @typescript-eslint/no-namespace */，或在ESLint配置中给组件库目录做特殊规则设置。

总之，只要是在ES模块内部用命名空间封装与核心API关联的类型，而非用命名空间替代ES模块本身，这种做法就是合理的，不少主流组件库也采用了类似的类型组织思路。

内容的提问来源于stack exchange，提问作者Natasha