Why are TS get/set definedProperties in a class transpiled as enumerable/writable?

[wardbell]

I just confirmed in the TS Playground that the following TS:

class Foo {
    get bar() { return true;}
}

Produces this JS:

var Foo = (function () {
    function Foo() {
    }
    Object.defineProperty(Foo.prototype, "bar", {
        get: function () { return true; },
        enumerable: true,
        configurable: true
    });
    return Foo;
})();

This MDN link confirms that, for Object.definedProperty accessors:
• enumerable: Defaults to false.
• configurable: Defaults to false.

Clearly the generated code is overriding the default values for these keys.

Plowing through the ES6 spec is not something I do. So I’m not sure that ES6 hasn’t changed the defaults. But I’d be surprised.

Now one of the things I miss in TS/ES6 class definitions is the ability to control these keys. It is also not easy to embellish a class with defined properties later … properties that might have non-default definitions

But that’s not my point or my question … which is, why is TS deviating from the defaults?

I get why I’d want the property to be enumerable most of the time – strange that the spec defaults to false. I don’t understand why I should want it to be configurable (maybe because I don't like something about the property TS generated for me?).

In any case, I don’t get how TS (or ES6) gets away with changing the ES5 defaults.

[DanielRosenwasser]

This might actually be a bug.

14.5.14 Runtime Semantics: ClassDefinitionEvaluation

With parameter className.

    ClassTail : ClassHeritage_opt { ClassBody_opt }

[...]
For each ClassElement m in order from methods

1. If IsStatic of m is false, then
2. Let status be the result of performing PropertyDefinitionEvaluation for m with arguments proto and false.
3. Else,
4. Let status be the result of performing PropertyDefinitionEvaluation for m with arguments F and false.

That second parameter to PropertyDefinitionEvaluation is enumerable.

Though, PropertyDefinitionEvaluation sets [[Enumerable]] to true, so the current behavior may be correct in that respect. (referenced wrong section)

This part of the spec is hard to trace and it would be good to have more eyes on this if possible.

[mhegazy]

/CC: @bterlson

[gilamran]

Sorry for polluting this discussion, but why isn't the result code just use ES5 getters/setters ? Why use defineProperty?

[mhegazy]

@gilamran you want to put the instance getters/setters on the prototype of the constructor function, and the static ones on the function itself. there is no other way to create something that is both a function, and set properties on it. you can do this with object literals, but then they are not functions.

[gilamran]

@mhegazy Got it, thanks!

[bterlson]

Sorry I'm late to this thread...

Class methods and getters/setters are created with enumerable false, configurable true, writable true. Seems like an ES6 conformance bug.

(The rationale here was in part to align classes with the built-in types, eg. consider that Array.prototype.* are non-enumerable).

[DanielRosenwasser]

Thanks for clarifying @bterlson, and thanks for noticing @wardbell.