Bug: no-underscore-dangle not working as expected in ES2022 public/private class fields

[robertotcestari]

Environment

Node version: 16.13
npm version: 8.1.2
Local ESLint version: 8.14.0
Global ESLint version: -
Operating System: macOS m1 pro

What parser are you using?

Default (Espree)

What did you do?

Configuration

{
  "extends": "eslint:recommended",
  "env": {
    "browser": true,
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 2022
  },
  "rules": {
    "no-underscore-dangle": [
      2,
      {
        "enforceInMethodNames": true
      }
    ]
  }
}

What did you expect to happen?

The rule no-underscore-dangle should also apply to the new ES2022 public/private class fields.
The implementation was marked done #14857 , however, it still does not work, as no errors are shown in public/private class fields.

What actually happened?

Errors were raised only for methods in the class (and properties in the constructor), but not for methods or properties defined via public/private class fields syntax.

Participation

• I am willing to submit a pull request for this issue.

Additional comments

No response

[btmills]

I was able to repro this in the demo (or the new demo!).

/* eslint no-underscore-dangle: ["error", { "enforceInMethodNames": true }] */

class Class {
  _publicField = "false negative";
  #_privateField = "false negative";
  
  _publicMethod() { return "true positive"; }
  #_privateMethod() { return "true positive"; }

  constructor() {
    this._publicField = "true positive";
    this.#_privateField = "true positive";
  }
}

In my opinion, class fields are new enough that we could fix this in a semver-minor release. If the team disagrees, the alternative is putting this check behind an option just like enforceInMethodNames, so potentially enforceInClassFields, which defaults to false to maintain compatibility with the current behavior and then default it to true in the next major release.

[robertotcestari]

The option enforceInClassFields is a great suggestion, @btmills . There is this #15811, but i am happy to submit another code with the enforceInClassFields option property.

[mdjermanovic]

Since this is a stylistic rule, and it already doesn't check all identifiers (for example, it allows property names in object literals), I think we should add this new check behind an option to maintain compatibility with the current behavior.

enforceInClassFields (default false) sounds good to me.

[robertotcestari]

Hi @btmills @mdjermanovic, just submitted a new PR (#15818) with

• New option enforceInClassFields (default false)
• Test cases
• Changes in documentation where appropriate.

This should fix and address your suggestions.