Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Support for #private class members #3430

Closed
Labels
ASTPRs and Issues about the AST structurebreaking changeThis change will require a new major version to be releasedpackage: typescript-estreeIssues related to @typescript-eslint/typescript-estree
Milestone
@bradzacher

Description

@bradzacher

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

classFoo{  #property=1;  #method(){}    #overloadedMethod():void;  #overloadedMethod():string{return''}get #accessor(){return1}set #accessor(value){}//// Static//static #staticProperty=1;static #staticMethod(){}static #staticOverloadedMethod():void;static #staticOverloadedMethod():string{return''}staticget #staticAccessor(){return1}staticset #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 - theClassProperty node.

When TS3.8 was released, the the three proposals for class members -class fields,static class features, andprivate 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 theTypeScript-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/

Metadata

Metadata

Assignees

No one assigned

    Labels

    ASTPRs and Issues about the AST structurebreaking changeThis change will require a new major version to be releasedpackage: typescript-estreeIssues related to @typescript-eslint/typescript-estree

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp