Update: Rename and deprecate misnamed option

[jrpool]

Object option allowMultiplePropertiesPerLine is stricter than the name implies.
It creates an exception to object-property-newline only if ALL properties are
on a SINGLE line. Renamed accordingly. Old name left deprecated, and 2 tests with
deprecated name (1 valid and 1 invalid) left in force.

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[X] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What rule do you want to change?
object-property-newline

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

How will the change be implemented? (New option, new default behavior, etc.)?
Replacement of old property name with new one, except that old name remains as deprecated and is still (rudimentarily) tested for.

Please provide some example code that this change will affect:

const object = {a: 1, b: 2, c: 3};

What does the rule currently do for this code?
Permits it if object-property-newline is enabled, but only if its allowMultiplePropertiesPerLine option is set to true.

What will the rule do after it's changed?
Permit it if object-property-newline is enabled, but only if either its allowMultiplePropertiesPerLine option or its allowAllPropertiesOnSameLine option is set to true.

What changes did you make? (Give an overview)
Documented the allowMultiplePropertiesPerLine option as deprecated and added 2 tests for that option. Otherwise, changed that option throughout to allowAllPropertiesOnSameLine.

Is there anything you'd like reviewers to focus on?

[aladdin-add]

LGTM, but I think it should be Update, instead of Chore. 😄

[jrpool]

Thanks, @aladdin-add. The Developer Guide says the Update tag is for “a backwards-compatible enhancement or a change to a rule that increases the number of reported problems”. Does a change like this increase the number of reported problems? If not, do you think that the description of Update is not correct?

[ilyavolodin]

@jrpool Chore is usually for internal tasks that have no affect on the end product. Like adding additional unit tests, refactoring, etc. This is an update to a rule, that adds a new option. It's backwards compatibly, since it preserves the old option, but it still introduces new option to the rule, so it should be marked as Update. Second part of the description of the update tag is not necessary (as in, update can introduce more errors, but doesn't have to).

[platinumazure]

@jrpool That description is grammatically ambiguous but I think it's supposed to read like this: "a backwards-compatible enhancement, or a change to a rule that increases the number of reported problems". This change is the first... Make sense?

[jrpool]

Thank you, @ilyavolodin and @platinumazure. I suspected that ambiguity but thought the most natural interpretation was with the qualifier modifying both alternatives. I have amended the description of this PR and the heading of the commit. I can submit another PR disambiguating the tag definition in the developer doc.

[platinumazure]

LGTM, thanks! We just need to evaluate the overall proposal, hopefully we can get that done soon.

[platinumazure]

I'll champion this.

@eslint/eslint-team Can we please evaluate this proposal? The object option is currently misnamed and it would be good to address this (in a backwards compatible manner, of course).

@ilyavolodin @aladdin-add Since you approved the PR, are you willing to 👍 the proposal?

[kaicataldo]

@eslint/eslint-team We just need one more 👍

[platinumazure]

Marking as accepted (champion: me, 👍s: ilyavolodin, kaicataldo, mysticatea).

[kaicataldo]

LGTM. Thanks for contributing to ESLint!