🔍 Search Terms

decorators, metadata, emitDecoratorMetadata, "TC39 decorators", "type information", reflect-metadata

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I want to be able to have design-time type information at runtime after the implementation of the new TC39 decorators system.

After the implementation of the TC39 decorators in Typescript 5.0 the ability to emit design-time type information has been lost unless we keep using the experimental (legacy) decorators system.

The suggestion is to allow to use emitDecoratorMetadata: true with experimentalDecorators: false. The idea is to expose the same metadata that it was being exposed to Reflect.metadata("design:type", type) with the legacy decorators, to the new metadata system proposed by TC39 that has been implemented in Typescript 5.2.

So, instead of using the obsolete reflect-metadata like Reflect.getMetadata('design:type', target, property), we can get the same info by doing something like SomeClass[Symbol.metadata]["design:type"].

📃 Motivating Example

After the decorators change, many existing and widely used libraries will have problems implementing their behaviors without type information at runtime: type-graphql, inversify, Angular 2,... or any other library which depends on reflect-metadata.

💻 Use Cases

As explained in the "Motivating Example", there are several existing use cases that require some kind of design-time type information at runtime. My suggestion is to use more or less the same approach you used with the experimental decorators, but with the standard ones. But I will mostly agree to any other approach that makes this information available at runtime.

For now, the workaround is to keep using the experimental decorators and the reflect-metadata library (or compatible). But I think it is worth giving the standard ones the same ability to expose this info.