Update rules to support ES2022 class fields

What is the name of the syntax to implement?

Class fields

Please provide the TC39 URL for the syntax proposal:

• Private methods and getter/setters for JavaScript classes
• Class field declarations for JavaScript
• Static class features

Implementation Checklist

This issue tracks rules that need to be updated to support ES2022 class fields. Please add to this list if there are any additional rules that need to be updated. I’ve linked to any comments on the original PR for easier reference. Some rule updates may have been finished in #14591, in which case we can confirm the updates are sufficient and check off the rule here.

• camelcase https://github.com/eslint/eslint/pull/14966
  • https://github.com/eslint/eslint/pull/14591#discussion_r676212379
• class-methods-use-this https://github.com/eslint/eslint/pull/15018
  • https://github.com/eslint/eslint/pull/14591#discussion_r656613541
  • https://github.com/eslint/eslint/pull/14591#issuecomment-866383434
  • https://github.com/eslint/eslint/pull/14591#issuecomment-877815299
• complexity https://github.com/eslint/eslint/pull/14957
  • https://github.com/eslint/eslint/pull/14591#issuecomment-877346829
• computed-property-spacing
• dot-notation https://github.com/eslint/eslint/pull/14898
  • https://github.com/eslint/eslint/pull/14591#issuecomment-866334741
• func-name-matching https://github.com/eslint/eslint/pull/14964
  • https://github.com/eslint/eslint/pull/14591#issuecomment-877324627
• func-names https://github.com/eslint/eslint/pull/14908
  • https://github.com/eslint/eslint/pull/14591#issuecomment-875789724
• id-denylist: https://github.com/eslint/eslint/pull/14591
• id-length: https://github.com/eslint/eslint/pull/14591
• id-match: https://github.com/eslint/eslint/pull/14591
• indent
• keyword-spacing https://github.com/eslint/eslint/pull/14946
  • https://github.com/eslint/eslint/pull/14591#pullrequestreview-701480702
• lines-between-class-members https://github.com/eslint/eslint/pull/15045
  • https://github.com/eslint/eslint/pull/14591#issuecomment-875113378
• no-dupe-class-members https://github.com/eslint/eslint/pull/15005
  • ~https://github.com/eslint/eslint/pull/14591#issuecomment-866757464~
• no-eval
• no-extra-parens https://github.com/eslint/eslint/pull/14906
  • https://github.com/eslint/eslint/pull/14591#issuecomment-866388926
• no-extra-semi
• no-invalid-this
• no-multi-assign https://github.com/eslint/eslint/pull/14907
  • https://github.com/eslint/eslint/pull/14591#pullrequestreview-701805427
• no-self-assign
• no-undef-init https://github.com/eslint/eslint/pull/14994
  • https://github.com/eslint/eslint/pull/14591#discussion_r656622751
  • ~https://github.com/eslint/eslint/pull/14591#issuecomment-875764498~
• no-underscore-dangle
• no-unreachable https://github.com/eslint/eslint/pull/14920
  • https://github.com/eslint/eslint/pull/14591#pullrequestreview-700195963
  • https://github.com/eslint/eslint/pull/14591#issuecomment-874951639
• no-useless-computed-key https://github.com/eslint/eslint/pull/14903
  • https://github.com/eslint/eslint/pull/14591#pullrequestreview-690053478
• operator-linebreak https://github.com/eslint/eslint/pull/14915
  • https://github.com/eslint/eslint/pull/14591#issuecomment-874963573
• prefer-destructuring https://github.com/eslint/eslint/pull/14897
  • https://github.com/eslint/eslint/pull/14591#issuecomment-874891668
• prefer-exponentiation-operator
• quotes
• semi-spacing
• semi-style
• semi https://github.com/eslint/eslint/pull/14945
  • https://github.com/eslint/eslint/pull/14591#issuecomment-866328829
  • https://github.com/eslint/eslint/pull/14591#issuecomment-874716539
  • https://github.com/eslint/eslint/pull/14591#issuecomment-876244868
• space-infix-ops

Are you willing to submit a pull request to implement this syntax?

We can work on these in parallel. To avoid redundant effort, please claim a rule when you start working on it.

[mdjermanovic]

All planned tasks are done 🎉

I made a quick pass through all rules to check if anything should be additionally updated because of the new code path and new scope for class field initializers, and I didn’t see any problems.

If anyone finds more rules that need to be updated, please open new issues.

[nzakas]

@mdjermanovic I think no-undef-init should not apply to class fields. If we do anything, I think a separate rule would make sense, though I’m not sure it’s important enough to warrant a core rule. I’ll defer to consensus on that.