Emit of union type metadata in nullStrictMode is always Object

[dqweek]

TypeScript Version: 2.1.1 / nightly (2.2.0-dev.201xxxxx)

function annotation(): PropertyDecorator {
    return (target: any, key: string | symbol): void => { };
}

class A {

    @annotation()
    field: B | null | undefined;
}

class B {
    field1: number;
}

Expected behavior:

function annotation() {
    return function (target, key) { };
}
var A = (function () {
    function A() {
    }
    __decorate([
        annotation(), 
        __metadata('design:type', B)
    ], A.prototype, "field", void 0);
    return A;
}());
var B = (function () {
    function B() {
    }
    return B;
}());

Actual behavior:

function annotation() {
    return function (target, key) { };
}
var A = (function () {
    function A() {
    }
    __decorate([
        annotation(), 
        __metadata('design:type', Object) //<-- should be B
    ], A.prototype, "field", void 0);
    return A;
}());
var B = (function () {
    function B() {
    }
    return B;
}());

[dqweek]

believed to be related to issues #11391, #10809

[mhegazy]

Union types are emitted as Object since there is no way to express the union using runtime values.

[dqweek]

I disagree. I don't argue that all union types should behave like I have mentioned, but only when single type unioned with null or undefined or both.
I see this union as special case, cause the only type you should to emit is the B type, null and undefined by them self are not types, but definition for missing states (so they don't need to be reflected in meta in any way)

if you still think it is working as intended. please mark this future as Breaking change

Till the use of strictNull I could do the following:

class A {}

class B
{
   @dec()
   field: A
}

const variable: B;
variable.field = null;

and the code would compile as expected and field type would be emitted as expected allowing me at Runtime to expect it and use it.

now, when the strict flag is on, all fields that can accept null or undefined, emitted as Object type, which become the metadata unusable in my case and I guess for others who relied on this behavior

[mhegazy]

if you are not using --strictNullChecks, both null and undefined are in the domain of all types. so you could assign null to any variable with no errors. with --strictNullChecks, this becomes more strict, and you need to mark ones that accept null or undefined

[dqweek]

I understand that,
I want to enjoy the strict mode future and it great code analysis, but still without loosing all benefits of the less strict mode that I was using before.

the null | undefined addition was seemed straight forward change, but now cause of the union definition, the metadata loosing it purpose, and it breaking my code that relies on this emit.

I looking a way to enjoy both worlds :-)

[mhegazy]

why is Foo | null any different from Foo | number?

[dqweek]

As I see it,

Foo | number union is splitted to two different valid types in javascript world. number is primitive type and Foo is descendant of Object type.

Foo | null union is a more special case. if we try to split it, we will find only Foo type and null hint for compiler, tells that field defined with that union can have valid Foo type or being null reference. from JavaScript perspective, null is not a Object descendant or primitive type.

this definition could be the same:

let defined: @null() decorator that hints compiler, field can have null reference
let defined: @undefined() decorator that hints compiler, field can have undefined state

then in theory this definition should be equal:

class A
{
     field: Foo | null | undefined;
}

class B
{
    @Null()
    @Undefined()
    field: Foo;
}

on both cases the compiler will understand the hint for allowing null | undefined definitions and code analysis would work, but in A type the union will emit Object type meta, in B the emit will be B type

for my opinion, the null, undefined tokens should be ignored only on metadata emit, they should still continue to participate in all other aspects for the union analysis logic