TypeScriptToLua项目中命名空间内装饰器导致未定义导出问题分析

问题概述

在使用TypeScriptToLua进行TypeScript到Lua的代码转换时，开发者在命名空间(namespace)内部对类使用装饰器(decorator)时遇到了一个编译问题。当命名空间中的类被装饰器修饰后，转换后的Lua代码会尝试向一个未定义的___exports变量进行赋值操作，导致运行时错误。

问题现象

通过对比两个简单的示例文件可以清晰地看到这个问题：

无装饰器版本(TypeScript)

namespace Repro {
    export class WithoutDecorator {}
}

有装饰器版本(TypeScript)

namespace Repro {
  @Decorator
  export class WithDecorator {}
}

转换后的Lua代码差异明显。无装饰器版本生成的代码完全正常，而有装饰器版本会在最后添加一行____exports.WithDecorator = WithDecorator的赋值语句，由于____exports未定义，导致运行时抛出"attempt to index global '____exports' (a nil value)"错误。

技术背景

在TypeScript中，命名空间是一种组织代码的方式，可以将相关的代码分组到一起。装饰器则是一种特殊类型的声明，可以附加到类声明、方法、访问符、属性或参数上，用来修改类的行为。

TypeScriptToLua在转换过程中，对于模块系统会使用____exports表来处理模块导出，但对于命名空间这种全局结构，本不应该使用模块导出机制。

问题根源

这个bug的根本原因在于TypeScriptToLua的转换逻辑中，装饰器处理逻辑没有正确区分模块导出和命名空间导出的场景。当检测到装饰器时，转换器错误地认为这是一个需要导出的类，因此生成了向____exports赋值的代码，而实际上命名空间中的类应该直接成为命名空间的成员。

解决方案

目前官方尚未修复此问题，开发者可以采用以下临时解决方案：

1. 手动全局注册：在类定义后手动将类赋值给全局表_G或globalThis

   namespace Repro {
     @Decorator
     export class WithDecorator {}
   }
   globalThis.WithDecorator = Repro.WithDecorator;
   

2. 避免在命名空间内使用装饰器：将需要装饰的类移出命名空间，或者改用其他方式实现装饰器的功能

3. 修改生成的Lua代码：通过构建后处理脚本移除错误的导出语句

最佳实践建议

在使用TypeScriptToLua时，对于需要在全局空间使用的类，建议：

1. 优先考虑使用模块系统而不是命名空间
2. 如果必须使用命名空间，尽量避免对命名空间内的类使用装饰器
3. 对于需要全局访问的类，考虑直接使用模块导出机制
4. 密切关注TypeScriptToLua的更新，及时获取此问题的官方修复

总结

这个bug展示了TypeScript到Lua转换过程中模块系统与命名空间系统交互时可能出现的问题。理解转换器的工作原理有助于开发者规避类似问题，并选择最合适的代码组织方式。对于依赖装饰器功能的项目，目前建议采用手动全局注册的方式作为临时解决方案，同时等待官方修复此问题。