computed-property-spacing new option for class members

[mdjermanovic]

What rule do you want to change?

computed-property-spacing

Does this change cause the rule to produce more or fewer warnings?

More if the option is set.

How will the change be implemented? (New option, new default behavior, etc.)?

New option.

Please provide some example code that this change will affect:

/*eslint computed-property-spacing: ["error", "never", { "classMembers": true }]*/

class foo {
  [bar ]() {}
}

What does the rule currently do for this code?

Nothing.

What will the rule do after it's changed?

Report warning / fix spacing.

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

Yes.

[mdjermanovic]

If the option from the start checks all members that have computed === true (in order to avoid adding new options in the future if public instance fields and static public fields can be computed) then classMembers or classElements name might be ok.

If the option checks only MethodDefinition (including static) perhaps it would be better to name it classMethods.

[platinumazure]

I'll champion this.

I like classMembers (or maybe enforceForClassMembers) and doing semver-minor updates to the rule as language features get to stage 4. But I'm open either way (re: whether to only cover methods for now).

[mdjermanovic]

I like classMembers (or maybe enforceForClassMembers)

There are already similar names:

• enforceForArrowConditionals in no-extra-parens
• enforceForRenamedProperties in prefer-destructuring

The convention that something = true means 'enforce for something' instead of 'allow something' might be confusing. It was confusing to me as well, now I'm used to it.

I like enforceForClassMembers as with such name there are no doubts what true or false means.

On the other hand, the majority of existing options do follow the above convention and it makes the names shorter.

I'm not sure what would be better, but it makes sense that whatever will be decided should apply to all future options.

doing semver-minor updates to the rule as language features get to stage 4. But I'm open either way (re: whether to only cover methods for now).

I didn't know is it okay to expand the rule to a new class syntax without an option in a semver-minor update. In that case, there is no need to 'generically' check all computed members, it's better to work with the known syntax only.

[platinumazure]

I didn't know is it okay to expand the rule to a new class syntax without an option in a semver-minor update.

Apologies, I should clarify that this is just my own opinion and the team might disagree. And also, I probably should say it is case by case- depending on if users would see the new language feature as a natural extension of the old, and therefore one they would want to enforce the same style on. If there's any doubt, then of course we should have separate options.

But the more options we have, the harder it is to learn and to maintain the rule.

Maintaining projects like this can be tricky. 😄

[mdjermanovic]

This also needs one more 👍 to be accepted?

[mdjermanovic]

I'm working on this.

enforceForClassMembers