Question/Feature Request: `.props` to work on ES6 class instances

The following does not work because the defined properties are not enumerable:

class Foo {
  get bar() { return somePromise; }
  get baz() { return otherPromise; }
}

Promise.props(new Foo()).then(
  ({bar, baz}) => // doesn't resolve these properties
);

Personally I think it should resolve ES5 non-enumerable properties (such as those defined via ES6 classes). Presently, the code is getting the properties to resolve via Object.keys, which only lists own enumerable properties.

While we’re discussing this, I’d expect .props to resolve inherited properties as well. Is there an intentional reason for only resolving own properties that are enumerable? Or was this just an incidental side effect of using Object.keys for the enumeration?

Do others see value in this behaving one way or the other?

[spion]

We can’t support getter properties without also supporting all non-enumerable properties. Supporting all non-enumerable properties would break backward compatibility. If we ignore that and make a change in 4.0, there will no longer be a way for users to hide properties from the props method. A factory function seems like an adequate replacement, and the classes version will become less ugly once decorators become available.

So overall I’m -1 on this.

[benjamingr]

I presume the lack of response is that we all only ever used it for enumerable own properties when passing an object literal and not a class.

It was intended to not enumerate enumerable properties since someone might extend Object.prototype with an enumerable property and it’d break .props otherwise.