My Proposal is Suitable for this Project

Oct 13, 2025 by miodeya.com 94 views

Before You File a Proposal Please Confirm You Have Done The Following...

Before we dive into the proposal, it's essential to ensure that we've covered all the necessary ground. Here's a checklist to confirm that our proposal is suitable for this project:

[x] I have searched for related issues and found none that match my proposal.
[x] I have searched the current rule list and found no rules that match my proposal.
[x] I have read the FAQ and my problem is not listed.

My Proposal is Suitable for this Project

Our proposal meets the following criteria:

[x] My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
[x] My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
[x] I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

TypeScript has provided visibility modifiers (private foo) for class properties since its very first version. However, since ES2022, there is native support for private fields using the #foo syntax. This native syntax enforces field visibility at runtime, something that TypeScript visibility cannot do (see TS documentation).

The stronger encapsulation using #foo provides a better default for private fields compared to the TS modifiers (private foo). It would be good to have a rule to warn against uses of private foo and recommend using #foo. Niche cases where a private must leak can be handled through explicit ESLint exceptions.

Fail Cases

class GuessingGame {
  public guessCount: number;
  private readonly secret: number;

  public constructor() {
    this.guessCount = 0;
    this.secret = Math.floor(100 * Math.random());
  }

  public guess(n: number): string {
    this.bumpGuessCount();
    if (n === this.secret) {
      return "win";
    } else {
      return n < this.secret ? "too low" : "too  high";
    }
  }

  private bumpGuessCount() {
    this.guessCount += 1;
  }
}

In the above example, the private modifier is used for the secret property. This is a fail case because we want to recommend using the native private field syntax #secret instead.

Pass Cases

class GuessingGame {
  public guessCount: number;
  readonly #secret: number;

  public constructor() {
    this.guessCount = 0;
    this.#secret = Math.floor(100 * Math.random());
  }

  public guess(n: number): string {
    this.#bumpGuessCount();
    if (n === this.#secret) {
      return "win";
    } else {
      return n < this.#secret ? "too low" : "too  high";
    }
  }

  #bumpGuessCount() {
    this.#guessCount += 1;
  }
}

In the above example, the native private field syntax #secret is used for the secret property. This is a pass case because we want to recommend using the native private field syntax.

Additional Info

Visibility modifiers such as public, protected and private are specific to TypeScript. This rule targets only private which can be replaced with native private fields most of the time. It does not affect public or protected modifiers.

Why Prefer Native Private Class Field?

The native private field syntax provides stronger encapsulation and better default behavior compared to the TS modifiers. By preferring the native private field syntax, we can ensure that our code is more secure and maintainable.

Benefits of the Rule

The rule will provide the following benefits:

Improved code security: By preferring the native private field syntax, we can ensure that our code is more secure and less prone to errors.
Better code maintainability: The native private field syntax provides a more consistent and predictable way of defining private fields, making it easier to maintain and understand the code.
Improved code readability: The native private field syntax is more concise and easier to read compared to the TS modifiers.

Implementation

The rule will be implemented as a TypeScript ESLint rule. The rule will check for the presence of private modifiers in class properties and recommend using the native private field syntax instead.

Example Use Cases

The rule will be useful in the following scenarios:

When defining private fields in classes, the rule will recommend using the native private field syntax instead of the TS modifiers.
When refactoring code to use the native private field syntax, the rule will help identify areas where the TS modifiers are used and recommend replacing them with the native private field syntax.

Conclusion

Frequently Asked Questions

We've received several questions about the rule proposal "Prefer Native Private Class Field". Here are some of the most frequently asked questions and their answers:

Q: What is the purpose of the rule proposal?

A: The purpose of the rule proposal is to improve code security, maintainability, and readability by recommending the use of the native private field syntax instead of the TS modifiers.

Q: Why prefer the native private field syntax?

A: The native private field syntax provides stronger encapsulation and better default behavior compared to the TS modifiers. By preferring the native private field syntax, we can ensure that our code is more secure and maintainable.

Q: What are the benefits of the rule?

A: The rule will provide the following benefits:

Improved code security: By preferring the native private field syntax, we can ensure that our code is more secure and less prone to errors.
Better code maintainability: The native private field syntax provides a more consistent and predictable way of defining private fields, making it easier to maintain and understand the code.
Improved code readability: The native private field syntax is more concise and easier to read compared to the TS modifiers.

Q: How will the rule be implemented?

A: The rule will be implemented as a TypeScript ESLint rule. The rule will check for the presence of private modifiers in class properties and recommend using the native private field syntax instead.

Q: What are the example use cases for the rule?

A: The rule will be useful in the following scenarios:

When defining private fields in classes, the rule will recommend using the native private field syntax instead of the TS modifiers.
When refactoring code to use the native private field syntax, the rule will help identify areas where the TS modifiers are used and recommend replacing them with the native private field syntax.

Q: Will the rule affect public or protected modifiers?

A: No, the rule will only target the private modifier and will not affect public or protected modifiers.

Q: Can I opt out of the rule?

A: Yes, you can opt out of the rule by adding an ESLint exception. This will allow you to continue using the TS modifiers if you have a specific reason for doing so.

Q: How will the rule be enforced?

A: The rule will be enforced through ESLint, which will check for the presence of private modifiers in class properties and recommend using the native private field syntax instead.

Q: What are the next steps for the rule proposal?

A: The next steps for the rule proposal are to:

Finalize the implementation of the rule
Test the rule thoroughly
Review and refine the rule based on feedback
Publish the rule as a TypeScript ESLint rule

We hope this Q&A article has provided you with a better understanding of the rule proposal "Prefer Native Private Class Field". If you have any further questions or concerns, please don't hesitate to reach out.