Properties defined with JsProperty are not enumerable, do not work with spread operator about gwt HOT 1 OPEN

It looks like this is the expected behavior with types that define get/set methods (both by Object.defineProperties and es6 class definitions):

class Foo {
  get label() {
    return 1;
  }
}
a = {...new Foo()} 
a.label

yield undefined. If the get/set method is on an object rather than a type, the value is returned as expected:

var a = {
    get b() { return 'b' },
};
var b = { ...a }
b.b

returns the string "b".

Typescript understands this, but only to a point - classes are understood to have get methods that won't be enumerable, but once you add an interface into the picture, it no longer works:

interface IFoo {
  get label(): string;
}

class Foo implements IFoo {
  get label() {
    return 'foo';
  }
}

const foo = new Foo();
const ifoo: IFoo = new Foo();

const a = { ...foo };
const b = { ...ifoo };

In the above, a is recognized to have no properties, but as of 5.4.5, TS believes that b has a label string, whereas in reality it is undefined.

The https://github.com/Vertispan/jsinterop-ts-defs/ project is already emitting as correct of TS as we can, with the equivelent of the interface IFoo above having get/set methods on it. In theory something like microsoft/TypeScript#9726 could provide a way to explicitly indicate that these property accessors aren't enumerable, but from the TS example above, I'm inclined to think this might just be a bug in TS rather than a missing feature.

We could make a feature request at https://github.com/google/jsinterop-annotations/ to specify a new JsProperty#enumerable, but it might need to be tri-state, or specific to decorating methods rather than properties (since Java fields would be enumerable by default, as they are properties on the underlying js object, while java methods would not be enumerable, since they are on the class).

I'll leave this open for later discussion, but at this time we're not considering this to be a bug.

from gwt.