You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

如何在不违反@typescript-eslint/no-namespace规则下实现嵌套类型访问?

解决方案

完全可以避开@typescript-eslint/no-namespace规则实现相同的类型设计,以下两种方案都能满足你的需求:

方案一:嵌套接口定义

直接在User接口内部嵌套定义Name和Address接口,既不需要使用命名空间,又能保留通过User.Name、User.Address访问类型的能力,是最简洁的替代方案:

export interface User {
  readonly name: User.Name;
  readonly address: User.Address;

  // 嵌套定义关联类型
  interface Name {
    readonly first: string;
    readonly last: string;
  }

  interface Address {
    readonly country: string;
    readonly city: string;
  }
}

使用方式和你原来的命名空间写法完全一致:

// 声明User类型变量
const user: User = {
  name: { first: "John", last: "Doe" },
  address: { country: "USA", city: "New York" }
};

// 使用嵌套类型
const userName: User.Name = { first: "Jane", last: "Smith" };

方案二:独立类型+接口合并

如果觉得嵌套定义不够清晰,可以先定义独立的内部类型,再通过接口合并的方式把它们挂载到User上:

// 定义独立的内部类型(用前缀避免全局命名冲突)
interface _UserName {
  readonly first: string;
  readonly last: string;
}

interface _UserAddress {
  readonly country: string;
  readonly city: string;
}

// 定义User核心结构
export interface User {
  readonly name: _UserName;
  readonly address: _UserAddress;
}

// 合并User接口,关联嵌套类型
export interface User {
  Name: _UserName;
  Address: _UserAddress;
}

// 导出嵌套类型,让外部可通过User.Name访问
export type User.Name = _UserName;
export type User.Address = _UserAddress;

这个方案的优势是内部类型的定义更独立,同时依然保持了User作为统一入口的关联关系,完全避开了命名空间的使用。

关键说明

两种方案都完全符合@typescript-eslint/no-namespace规则要求,同时实现了:

  • 避免命名冲突:所有关联类型都通过User入口访问,不会污染全局命名空间
  • 体现类型关联:清晰表达Name、Address与User的从属关系
  • 用法一致:外部代码无需修改,依然可以通过User.Name、User.Address使用嵌套类型

内容的提问来源于stack exchange,提问作者Maksym Anurin

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.08.18 09:05:27