遵循TC39提案定义ClassDecorator，TypeScript 5报错，是用法问题还是API不完善？

错误原因 #

你碰到的TS1270错误，核心是TypeScript 5的标准装饰器（非legacy版本）对类装饰器的返回值类型有严格的兼容性要求：

类装饰器如果返回函数，必须是与原类构造函数兼容的类型，即满足new (...args: any[]) => 原类实例的签名。

你当前的装饰器返回defineComponent(vueOptions)生成的Vue组件构造函数，和目标类ReactiveStateExperimentalSample的构造函数类型完全不匹配——Vue组件的构造函数无法替代原类的构造函数（不满足new (): ReactiveStateExperimentalSample的签名），因此触发类型检查错误。

TC39提案与TS实现的差异 #

TC39提案中类装饰器的签名确实标注返回Function | void，但TypeScript 5实现的是Stage 3的标准装饰器，在类型系统上做了更严格的约束：

• 在lib.decorators.d.ts中，类装饰器的类型定义为：

  type ClassDecorator = <TFunction extends Function>(value: TFunction, context: ClassDecoratorContext) => TFunction | void;
  

  这里要求返回的函数必须是原构造函数TFunction的兼容类型，而非任意Function。
• 旧的legacy装饰器签名宽松，但已被废弃，TS5不再推荐使用。

解决方案 #

根据你的需求，有两种可行的调整方式：

方案1：使用context.addInitializer添加逻辑（推荐） #

标准装饰器设计的核心思路之一是通过addInitializer添加初始化逻辑，而非直接替换类构造函数。如果你的目标是给类绑定Vue组件配置，可改为：

const VueComponentOptions = (
  value: Function, context: ClassDecoratorContext
): void => {
  const vueOptions: ComponentOptions = {
    methods: {},
    computed: {}
  };

  // 在类初始化时执行Vue相关绑定逻辑
  context.addInitializer(() => {
    // 这里可以实现类与Vue组件的关联逻辑，比如注册组件、绑定实例等
    console.log(`关联Vue组件配置到类: ${context.name}`);
  });
};

方案2：返回兼容原类的构造函数 #

如果必须返回新的构造函数，需要确保它能兼容原类的构造函数签名。可以通过继承原类的方式实现：

const VueComponentOptions = <T extends new (...args: any[]) => {}>(
  value: T, context: ClassDecoratorContext
): T => {
  const VueComponent = defineComponent({
    methods: {},
    computed: {}
  });

  // 让Vue组件构造函数继承原类的原型和静态属性，保证类型兼容
  Object.setPrototypeOf(VueComponent.prototype, value.prototype);
  Object.setPrototypeOf(VueComponent, value);

  // 类型断言确保TS接受返回值
  return VueComponent as unknown as T;
};

注意：这种方式需要结合Vue的实际API调整，避免运行时原型链异常。

关于API成熟度 #

TypeScript 5的标准装饰器是稳定的生产级实现，对应TC39 Stage 3提案的规范。你遇到的问题并非API不成熟，而是对TS类型系统的额外约束理解偏差——TS通过严格的类型检查确保装饰器不会破坏类的类型一致性，这是类型安全的必要设计。

内容的提问来源于stack exchange，提问作者Takeshi Tokugawa YD