Rule proposal: prefer hash names for private members

[kimamula]

TypeScript 3.8 will add support for private named instance fields. What about creating a rule for disallowing the use of the private accessibility modifier in favor of the standard hash names for private members?

Examples of incorrect code for this rule:

class MyClass {
  private foo = 1;
  constructor(private bar: string) {}
}

Examples of correct code for this rule:

class MyClass {
  #foo = 1;
  #bar: string;
  constructor(bar: string) {
    this.#bar = bar;
  }
}

Options

// Any target whose hash names are supported
// by the TypeScript version in use can be specified
type Target =
//  | 'accessors'
//  | 'constructors'
//  | 'staticMethods'
//  | 'instanceMethods'
//  | 'staticFields'
  | 'instanceFields';

type Options = Target[];

// Defaults to all the targets
const defaultOptions: Options = ['instanceFields']; // for TypeScript 3.8

[glen-84]

Perhaps it should allow the opposite as well – enforcing soft (compile-time-only) privacy?

[bradzacher]

Probably best to be added as an option on the explicit-member-accessibility rule.

[kimamula]

Then the options for explicit-member-accessibility should be changed to something like the following?

type AccessibilityLevel =
  | 'explicit' // require an accessor (including public)
  | 'no-public' // don't require public
  | 'off'; // don't check

type PrivateMemberDeclaration =
  | 'private' // force private modifier
  | '#' // force hash names
  | 'off'; // don't check, default

type AccessibilitySetting = AccessibilityLevel | [AccessibilityLevel, PrivateMemberDeclaration];

type Options = {
  accessibility?: AccessibilitySetting;
  ignoredMethodNames?: string[];
  overrides?: {
    accessors?: AccessibilitySetting;
    constructors?: AccessibilitySetting;
    methods?: AccessibilitySetting | {
      static?: AccessibilitySetting;
      instance?: AccessibilitySetting;
    };
    properties?: AccessibilitySetting | {
      static?: AccessibilitySetting;
      instance?: AccessibilitySetting;
    };
    parameterProperties?: AccessibilitySetting;
  };
};

const defaultOptions: Options = {
  accessibility: 'explicit',
};

I'm afraid that the name explicit-member-accessibility is a bit confusing for this use case though.
Perhaps it should be renamed to something like member-accessibility and the name explicit-member-accessibility should remain as an alias for it?

[zheeeng]

Expect more discussions and progress on this issue.

[bradzacher]

With any issue in opened in this project - it either has a visible progress in the form of an attached PR, or it has no progress.

We are a community run project. The volunteer maintainers spend most of their time triaging issues and reviewing PRs. This means that most issues will not progress unless a member of the community steps up and champions it.

If this issue is important to you - consider being that champion.

If not - please just subscribe to the issue and wait patiently.
Commenting asking for status updates does not bump issue priority in any way and just serves to spam everyone subscribed to the issue.

[npdev453]

Current workaround:

'@typescript-eslint/naming-convention': [
  'error',
  {
    selector: ['property', 'parameterProperty', 'accessor'],
    modifiers: ['private'],
    prefix: ['#'],
    format: null,
  }
],

[bradzacher]

As per our FAQ article - this can easily be achieved using no-restricted-syntax:

no-restricted-syntax: [
    'error',
    {
        selector: ':matches(PropertyDefinition, MethodDefinition)[accessibility="private"]',
        message: 'Use #private instead',
    },
],

playground

similarly the inverse can easily be enforced as well:

no-restricted-syntax: [
    'error',
    {
        selector: ':matches(PropertyDefinition, MethodDefinition) > PrivateIdentifier.key',
        message: 'Use `private` instead',
    },
]

playground

I don't believe that a lint rule makes sense here. We want to avoid adding rules which just ban a specific language features unless we can add some real additional value. Given that there's no fixer we can provide (because it's unsafe), and there's no options to configure or tweak - I don't see any additional value we can provide.

For this reason, we shall reject this rule proposal.