"object-property-newline" rule: add option to allow shorthand properties on the same line

What rule do you want to change?

object-property-newline

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

Fewer

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

A new allowAllShorthandPropertiesOnSameLine option:

• allowAllShorthandPropertiesOnSameLine: true allows all the shorthand properties to be on the same line.
• allowAllShorthandPropertiesOnSameLine: false (default) disallows shorthand properties to be on the same line.

[Currently the only possible option is allowAllPropertiesOnSameLine]

Please provide some example code that this change will affect:

const object = {
    shortHandProperty1, shortHandProperty2, property3: "value3", property4: "value4"
};

What does the rule currently do for this code?

With ["error"], expects:

const object = {
    shortHandProperty1,
    shortHandProperty2,
    property3: "value3",
    property4: "value4"
};

What will the rule do after it’s changed?

With ["error", {allowAllShorthandPropertiesOnSameLine: true}], also validates:

const object = {
    shortHandProperty1, shortHandProperty2,
    property3: "value3",
    property4: "value4"
};

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

Yes

Comment

I haven’t found any style guide that explicitly recommends this, but it seems to be quite a common pattern to me.

[kaicataldo]

What happens if there are a lot of shorthand properties? It seems like you would be forced to do something like this (which I imagine could be viewed as undesirable, particular since it could conflict with max-len):

const object = {
    shortHandProperty1, shortHandProperty2, shortHandProperty3, shortHandProperty4, shortHandProperty5, shortHandProperty6, shortHandProperty7, shortHandProperty8,
    property3: "value3",
    property4: "value4"
};

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.