💻

• Would you like to work on a fix?

How are you using Babel?

@babel/cli

Input code

class Example {
  #foo = 123

  @deco
  set foo(v) {this.#foo = v}
  get foo() { return this.#foo }
}

function deco(_, context) {
  context.addInitializer(function () {
    // If this runs before fields are initialized, then it should be a runtime error due to the private field not being initialized yet:
    console.log('initial value:', this[context.name])
  })
}

new Example()

Configuration file name

babel.config.js

Configuration

See the repl

Current and expected behavior

Current behavior is in the following repl. The getter is able to read the #private field (this is very desirable, but the decorators proposal says that instead there should be an error which is a bit unfortunate):

repl

According to tc39 proposal-decorators's README,

Class element initializers run during class construction, before class fields are initialized.

The expected behavior (unfortunately, because I much prefer Babel's behavior) is that the getter should throw an error trying to read the private field from its own class. Here's a TypeScript example with the behavior as described in the proposal's README:

TS playground

Environment

See repl

Possible solution

Run the non-field initializers before field initializers.

Additional context

I like Babel's behavior more (I would like to read the getter to get its initial value in the initializer) and the fact that a private field in the same class as my getter is causing a runtime error is unfortunate.

If this will not change in the spec, I propose adding a new API context.addPostInitializer() that runs after field initializers. More details here:

• feature request (separate proposal?): context.addPostConstructInitializer() tc39/proposal-decorators#521