Proposal addition to object-shorthand: add consistent and consistent-as-needed

[martijndeh]

When does this rule warn? Please describe and show example code:
Similar to the quote-props rule, where it's possible to set the rule to consistent and consistent-as-needed, I'd like the object-shorthand rule to include these options as well.

When object-shorthand set to consistent, the below should not be considered a problem:

let obj1 = {
    foo: foo,
    bar: 'This is a string',
};

No problem:

let obj2 = {
    foo,
    bar,
};

The following should be considered a problem:

let obj1 = {
    foo,
    bar: 'This is a string',
};

Problem:

let obj2 = {
    a() {},
    bar: foo,
};

The consistent-as-needed is very similar, but if all keys are redundant, the following pattern is considered a problem:

let obj3 = {
    foo: foo,
    bar: bar,
};

The options apply to both properties and methods.

Is this rule preventing an error or is it stylistic?
Stylistic. Personally, I feel the shorthand syntax is great, but mixing it with the longform syntax makes it harder to scan/read code. In my rules, I want to allow the shorthand syntax, but only if it's consistent in that object literal.

Why is this rule a candidate for inclusion instead of creating a custom rule?
I think this is in line with other rules which also provide consistent and consistent-as-needed options (e.g. quote-props).

Are you willing to create the rule yourself?
Yes.

[platinumazure]

Maybe it's just that I don't do ES6 much, but I'm having a hard time distinguishing what is "shorthand" and what is not in your examples.

Can you tell me which of the properties below (1) do you consider "shorthand", and (2) does the rule consider "shorthand"? Thanks!

var obj = {
    foo,
    bar: bar,
    a: function () {},
    function a() {},
    get a() {},
    set a(value) {}
};

[martijndeh]

Sure. Please see the below annotated object literal:

var obj = {
    // This is shorthand and new syntax in ES6. The key is implicit. This was invalid in ES5.
    foo, 

    // This is longform as you need to explicitly state the key. This was valid in ES5.
    bar: bar, 

    // This is longform. You need to explicitly state the key. This was valid in ES5.
    a: function () {}, 

    // This is shorthand. This was invalid in ES5. The key is implicit.
    a() {}, 

    // This is a more ambiguous case. It's not included in the new object literal 
    // shorthand syntax as introduced in ES6, but it also doesn't explicitly state the key (it's 
    // very similar to the named function above).
    //
    // Personally, I consider this neither longform nor shorthand.
    get a() {},

    // Idem to the getter.
    set a(value) {} 
};

I have a PR coming up (see https://github.com/martijndeh/eslint/tree/feature/object-shorthand-consistent) which implements this feature. Personally I hardly use getters and setts inside object literals, so I decided to exclude these expressions from the consistency check.

This means the following is valid when setting the "consistent" option:

var obj = {
    foo,
    bar,
    get test() { return 1; }
};

But, the following is valid as well:

var obj = {
    foo: foo,
    bar: bar,
    get test() { return 1; }
};

When setting the "consistent-as-needed" option the following would be invalid:

var obj = {
    foo: foo, // should be foo
    bar: bar, // should be bar
    get test() { return 1; } // ignored
};

What do you think?

[platinumazure]

Thanks. FYI, we usually don't merge pull requests until the team has fully evaluated the issue and marked it as "accepted", so don't put too much time into polishing up the pull request (otherwise that time would be wasted if we reject the request). See this page for more info.

[michaelficarra]

You both seem to be confused about how to write methods.

({ a(){} });

[martijndeh]

Ah my bad. I shouldn't have included the function keyword in the shorthand function example in the original example. Edited.

[platinumazure]

@michaelficarra I did note I don't use or know ES6, hence asking the
question in the first place. Thank you for the education.
On Mar 1, 2016 8:55 AM, "Martijn de Haan" notifications@github.com wrote:

Ah my bad. I shouldn't have included the function keyword in the
shorthand function example in the original example. Edited.

—
Reply to this email directly or view it on GitHub
#5438 (comment).

[BYK]

I think we just need always-consistent or something to enforce consistency for cases when we cannot use the shorthand notation.

[martijndeh]

That's consistent-as-needed, right?

[BYK]

It's not really "as-needed". I mean "as-needed" as in "we need to not use the shorthand syntax", hence the confusion.

[martijndeh]

Can you give some examples when always-consistent would apply and not apply? You are suggesting it as an option in addition to the other options in the proposal, correct?

[nzakas]

@BYK I think the point is to keep the naming similar to existing options.

@eslint/eslint-team this proposal has been largely ignored. We need a champion and three 👍s to continue or else we should close this.

[BYK]

I guess that's fair, thus I'm not gonna provide examples for always-consistent case :)

[nzakas]

Sorry, lost track of this. @martijndeh are you still interested?

I'll champion this change since there's a PR already.

[martijndeh]

No worries. Yes. Personally I really want this rule. If there is support I'll make sure the PR gets fixed.

[nzakas]

@eslint/eslint-team can I get some 👍s for this? I think it makes sense and the PR is basically already done.

[gyandeeps]

👍

[mikesherov]

👍

[mysticatea]

Sounds good to me 👍

[nzakas]

Okay @martijndeh we are good to move forward. Sorry for the delay.