OpenAPI-TS 项目中关于可空枚举类型的生成问题解析

背景介绍

在 OpenAPI-TS 项目中，开发者们遇到了一个关于可空枚举类型生成的典型问题。当在 OpenAPI 规范中将枚举类型标记为可空(nullable)时，生成 TypeScript 类型和常量时会出现一些预期之外的行为。

问题现象

在 OpenAPI 规范中定义如下可空枚举字段时：

"headquartersCountry": {
  "type": ["string", "null"],
  "enum": ["AE", "ZM", "INVALID", null]
}

使用 OpenAPI-TS 0.67.3 版本会生成以下 TypeScript 代码：

export type HeadquartersCountry = 'AE' | 'ZM' | 'INVALID' | null;

export const HeadquartersCountry = {
    AE: 'AE',
    ZM: 'ZM',
    INVALID: 'INVALID',
    NULL: null
} as const;

而使用较早的 0.55.0 版本则生成：

export type HeadquartersCountry = 'AE' | 'ZM' | 'INVALID';

export const HeadquartersCountry = {
    AE: 'AE',
    ZM: 'ZM',
    INVALID: 'INVALID',
} as const;

技术分析

从技术角度来看，这个变化涉及到几个关键点：

1. 规范符合性：新版本更严格地遵循了 OpenAPI 规范，将 null 明确包含在枚举值和类型中，这从规范角度是正确的。

2. 开发者体验：虽然规范上正确，但在实际开发中，将 null 作为常量值可能会带来一些问题：

   • 在 UI 下拉菜单生成时，Object.values() 会包含 null 值
   • 在 Zod 验证中，NULL 常量会被视为有效值
   • 代码可读性和一致性受到影响

3. 类型系统影响：TypeScript 对 null 的处理需要特别注意，特别是在联合类型中。

解决方案

OpenAPI-TS 项目团队在 0.67.5 版本中引入了配置选项来解决这个问题：

{
  plugins: [
    {
      name: "@hey-api/typescript",
      enumsConstantsIgnoreNull: true // 新增配置
    }
  ]
}

这个配置允许开发者选择是否在生成的枚举常量中包含 null 值，平衡了规范符合性和开发便利性。

最佳实践建议

1. 明确设计意图：在设计 API 时，应明确区分"值不存在"(null)和"无效值"(如'INVALID')的概念。

2. 验证策略：在使用 Zod 等验证库时，考虑使用 .nullable() 方法而不是将 null 包含在枚举中。

3. 版本控制：升级 OpenAPI-TS 版本时，注意检查枚举相关的变更对现有代码的影响。

4. 文档说明：在团队内部文档中记录枚举处理策略，保持一致性。

总结

OpenAPI-TS 项目对可空枚举类型的处理演变展示了规范实现与开发者体验之间的平衡过程。通过引入配置选项，项目既保持了规范的准确性，又提供了适应不同开发场景的灵活性。理解这一机制有助于开发者更好地设计 API 规范和使用代码生成工具。