Support for #private class members

[bradzacher]

TS3.8 introduced support for #private properties.
TS4.3 introduced support for #private members.

class Foo {
  #property = 1;

  #method() {}
  
  #overloadedMethod(): void;
  #overloadedMethod(): string { return '' }
  
  get #accessor() { return 1 }
  set #accessor(value) { }

  //
  // Static
  //

  static #staticProperty = 1;

  static #staticMethod() {}
  
  static #staticOverloadedMethod(): void;
  static #staticOverloadedMethod(): string { return '' }
  
  static get #staticAccessor() { return 1 }
  static set #staticAccessor(value) { }
}

---

Background

Class properties are a pretty ubiquitous part of the JavaScript ecosystem. However until relatively recently they were actually not a fully specced out and stable feature. For years they sat in the "Stage 2" state, meaning that ESTree[1] did not move to implement them[2].

Because of this when TypeScript-ESTree implemented the AST for class properties, it followed the standards of the community at the time; which was Babel's AST representation - the ClassProperty node.

When TS3.8 was released, the the three proposals for class members - class fields, static class features, and private methods were still in Stage 2, meaning that there was no defined ESTree AST spec for the features.

So we were given two choices (1) implement private properties using Babel's AST or (2) wait to implement until the official spec was released.

When TS3.7 was released, it brought with it optional chaining (?.). At the time this feature similarly did not have an ESTree spec, and we implemented the feature using Babel's AST. Not long after we released that ESTree merged their spec for the feature, meaning we had to go through a fairly painful breaking change to rewrite our parser to support the spec, and the community had to transition all plugins to support the new spec.

This is why we chose to wait to implement support for private properties - to avoid churn within our project and the wider community.

Now that the previously mentioned class feature proposals have reached stage 3, ESTree has merged their representation. So now we can move to do a breaking change migration of our property representation to this new spec.

---

[1] ESTree is the AST specification that is used for ESLint. It is the specification that we extend to support TypeScript features (called the TypeScript-ESTree spec).

[2] ESTree does not implement an AST for features until they reach Stage 3. This is on purpose as features are not considered "stable" until they reach Stage 3. You can read more about the TC39 process here - https://tc39.es/process-document/

[dimitropoulos]

Thanks for the thoughtfulness and consideration for the community (and plugin designers)

[tchetwin]

Now that the previously mentioned class feature proposals have reached stage 3, ESTree has merged their representation. So now we can move to do a breaking change migration of our property representation to this new spec.

They reached stage 4 in a recent TC39 meeting and I believe this too was reflected in the ESTree repo.

[bradzacher]

This will be released in v5