Incorrect metadata emitted for property decorators when the property type is inferred (e.g. from an assignment), but not explicitly defined.

[JohnWeisz]

TypeScript Version: 2.1.4

Code

function PropDeco(target: Object, propKey: string | symbol) { }

class Foo {
    @PropDeco
    public foo = "bar";
}

Expected behavior:

Since the runtime type (constructor reference) of Foo.foo is supposed to be String, the compiler should emit String as the type of Foo.foo, as it does when the property has an explicitly defined type (i.e. foo: string = "bar"):

__metadata("design:type", String)

Actual behavior:

The compiler emits Object as the type of Foo.foo, which I believe is incorrect:

__metadata("design:type", Object)

[JohnWeisz]

The issue is also observable with getters/setters:

class Foo {
    @PropDeco
    public get foo() { return "bar" }
}

will emit:

__metadata("design:type", Object),

[mhegazy]

Looking at this issue again, this working as intened. We want to emit the same code regardless of what the type system thinks your code is. The scenario here is using the transpile/transpileModule functions where the whole project is not loaded, just a single file. so consider:

import {imported} from “./another”; 
class C { 
    @dec 
    public s = imported;
}

We want this to be always be the same type, and that is not possible if you call transpile/transpileModule since the other module is not loaded.

MetaData will only be whatever the explicitlly declared type annotation.

[JohnWeisz]

Although I understand the limitations described here, I respectfully disagree that this should be, or would be generally working as intended, at least in the scope of this single scenario. I'm not aware of the implementation of the metadata type-serialization system in TypeScript, but this seems wrong:

MetaData will only be whatever the explicitlly declared type annotation.

In practice, this means that a property with an explicitly declared type annotation and a property with an inferred type are semantically two different things. Two different things which, while identical at compilation, are deemed different at runtime.

class C { 
    @dec
    public s = 7;

    @dec
    public s2: number = 7;
}

To the best of my knowledge, C.s and C.s2 are treated identically regarding their types. I see no reason it should be intentional for them to be treated differently at runtime, unless this is a serious limitation we are talking about, that would require disproportionately large amounts of work to get around.

[mhegazy]

@JohnWeisz, is this is a limitation of the current system. we would be open to suggestions on how to support the scenario i have outlined above.