Improvement: Design metadata should contain property names and types

At the moment it's not possible to get all Properties of a Type with the corresponding design-type of the property.
It's only possible to get all properties of an object by using Object.keys() and this wouldn't return properties which haven't been set, of course the simply don't exist.
So it wold be a great feature, if a class which emits metadata because of a decorator would also emit a metadata called something like 'design:properties' which contains a list of all property-names with the corresponding type.

Can you elaborate on the scenario you are trying to achieve?

Alright lets take a look at this simple class:

export class MyClass{
    public stringProperty: string;
    public numProperty: number;
    constructor(stringParam: string){
    }
}

with --emitDecoratorMetadata the following code is emitted:

var MyClass = (function () {
    function MyClass(stringParam) {
    }
    MyClass = __decorate([
        my_decorator_1.myDecorator, 
        __metadata('design:paramtypes', [String])
    ], MyClass);
    return MyClass;
}());

I think it would be useful, if the emitted js would contain additional metadata which describes the designtime properties of the class:

var MyClass = (function () {
    function MyClass(stringParam) {
    }
    MyClass = __decorate([
        my_decorator_1.myDecorator, 
        __metadata('design:paramtypes', [String])
        __metadata('design:properties', [
        {name: 'stringProperty', type: String, visibility: 'public'},
        {name: 'numProperty', type: Number, visibility: 'public'}
        ])
    ], MyClass);
    return MyClass;
}());

So Reflect.getMetadata can be used to get all properties of a type in the same way it can be used to get all parameters of the constructor:

let constructorParams = Reflect.getMetadata('design:paramtypes', MyClass);
let propeties = Reflect.getMetadata('design:properties', MyClass);

I hope this makes the scenario more understandable

For what it's worth, I agree with this feature request entirely. The exact format of the properties and the name of the metadata decorator are up for interpretation, but the feature itself needs to be here in some form.

A question that comes to mind (not a problem): should we store "readonly" and other type modifiers in this way?

With the recent decision to emit assignments of undefined for class property declarations without an initializer this might make more sense than it once did. This might have to be under an additional flag as the size of the emit would increase dramatically.

@aboveyou00 I don't think serializing private, public, or readonly would make sense at this point. Certainly not until the private fields proposal works its way further through TC39.

Hi, any news?

Cedware

There has been almost one year. Are there any updates on this? Cedware Mohamed Hegazy (@mhegazy)

Aluan Haddad (@aluanhaddad)

This is exactly what I need! What's the status on this?

Also, Aluan Haddad (@aluanhaddad), what do you mean by "the recent decision to emit assignments of undefined for class property declarations without an initializer"? That sounds very promising for what I'm trying to do, but I'm not sure what you're referencing and google with those and similar search terms doesn't turn up anything for me.

Is there a way to make USE_NEW_TYPE_METADATA_FORMAT=true for
https://github.com/Microsoft/TypeScript/blob/90b304aa5e93a8195e4b8bcfb65b0079391cb9cf/src/compiler/transformers/ts.ts#L1659-L1661

It will unlock desired behavior
https://github.com/Microsoft/TypeScript/blob/90b304aa5e93a8195e4b8bcfb65b0079391cb9cf/src/compiler/transformers/ts.ts#L1681-L1697

Ron Buckton (@rbuckton)

This feature was reverted in #7878 by Ron Buckton (@rbuckton)

Mohamed Hegazy (@mhegazy) said on Apr 7, 2016

As discussed offline, we should limit the breaking change for this iteration, and include these changes later on.

But what about just adding design:typeinfo to the old method addOldTypeMetadata without breaking changes?
https://github.com/Microsoft/TypeScript/blob/90b304aa5e93a8195e4b8bcfb65b0079391cb9cf/src/compiler/transformers/ts.ts#L1693-L1695

Paul Damnhorn (@nodkz)

Paul Damnhorn (@nodkz) is this really possible? I am hunting these new features of TS that are about to be introduced. for one of my projects.

These features will make Typescript become a next level language. I think we need to add a flag or something to ts that opens a new set of features like this.

Ionel lupu (@IonelLupu)

Ionel lupu (@IonelLupu) it possible if you write own custom transpiler via Compiler API and use ttypescript.

Doesn't every other programming language that support annotations at least allow you to list them from a class?

In my opinion, there really has to be an easier way to include decorators and annotations..

The biggest use case (that I've noticed), is that people just want to annotate and find out fields and classes that have annotations on the fields, parameters, classes, methods at runtime.

There should be a standard way that one can just create a class that can be used for annotations like in Java. Some standard boilerplate that can be included from say, reflect-metadata.

Then have standard functions that allow you to get from a class or method and a 'get all annotations from' as well.

This is still work in progress but I've developed a little decorator that allow the user to retrieve such information from the decorated class properties: https://github.com/guillotjulien/object-seeder

I'm also working on a V2 that should address some of the flaws of the current implementation, but I've been using V1 since ~1 year (prior to NPM package) on multiple enterprise projects without any significant issues.

For example, we used those metadata to create a SQL like DSL that can validate selected properties against model available properties.

We also need this feature for our project (making DI bean resolutions depends on param names too).

I've made modification in tsc.ts to emit design:paramnames metadata too. I can not create PR because there is no associated issue with Backlog milestone (tests are updated, PR merge-able).

I did put the param names resolution into the same serialization function as the param types, so param names will be emitted when param types will.
I renamed this serialization function.

You can check the diff at master...sekko27:master

Could you assign the Backlog milestone for this issue?

is this issue alive?

I hope so

In particular, I would really like to be able to get the value of a read-only instance property, which should theoretically be available from a static context.

I may need to do something weird where there's a static property and the read-only instance property is always set to the static value...

I am definitely interested in reflecting upon visibility, the list of class properties themselves, and even more importantly: instructing Typescript to emit metadata for all compiled code. I'm certainly willing to incur longer startup times and higher memory usage to enable this. I don't believe that emitting RTTI for all types will cause ongoing runtime perf but would love to hear otherwise if it's believed to be the case.

I hope feature development around RTTI is still being considered!

Currently looking for this functionality too including the possiblity to check wether or not a decorated attribute is optional or not so it could look like this?

        {name: 'numProperty', type: Number, visibility: 'public', optional: true}

Matthias von Bargen (@mattvb91)

Matthias von Bargen (@mattvb91) Looking for this feature as well.

What typescript compilers are you all using to get this information until we wait for Typescript to support this by default?

Ionel lupu (@IonelLupu)

Ionel lupu (@IonelLupu) currently trying to use the compiler API to parse it out manually but it could definitey be made a lot simpler by including this feature here

https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API

There have been many attempts at doing this in a transformer, but they all have had deficiencies. I'm throwing my hat in the ring with a new attempt:

https://github.com/rezonant/typescript-rtti

Would love to hear any feedback (on that project, so as to keep noise down for the subscribers here), and especially for people to try it out against their codebases as there may be corner cases that don't work just yet.

Navigation Menu

Repository navigation

Improvement: Design metadata should contain property names and types #12626

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Improvement: Design metadata should contain property names and types #12626

Description

Activity

mhegazy commented on Dec 3, 2016

Cedware commented on Dec 3, 2016

leviathanbadger commented on Jan 19, 2017

aluanhaddad commented on Jan 19, 2017

listepo-alterpost commented on Sep 19, 2017

IonelLupu commented on Aug 14, 2018

IRCraziestTaxi commented on Mar 23, 2019

nodkz commented on Apr 9, 2019

nodkz commented on Apr 9, 2019

IonelLupu commented on Aug 2, 2019

nodkz commented on Aug 2, 2019

cyraid commented on Apr 13, 2020

guillotjulien commented on Jun 21, 2020

sekko27 commented on Sep 18, 2020

sekko27 commented on Oct 26, 2020

mdnmdn commented on Dec 19, 2020

DHager commented on Jan 27, 2021

rezonant commented on Feb 19, 2021

mattvb91 commented on Mar 4, 2021

IonelLupu commented on Mar 5, 2021

mattvb91 commented on Mar 5, 2021

rezonant commented on Mar 5, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions