Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require Object Literal Shorthand Syntax (object-shorthand) #1354

Open
feross opened this issue Aug 12, 2019 · 6 comments
Open

Require Object Literal Shorthand Syntax (object-shorthand) #1354

feross opened this issue Aug 12, 2019 · 6 comments

Comments

@feross
Copy link
Member

feross commented Aug 12, 2019

Thoughts on enabling this rule? https://eslint.org/docs/rules/object-shorthand

ECMAScript 6 provides a concise form for defining object literal methods and properties. This syntax can make defining complex object literals much cleaner.

Here are a few common examples using the ES5 syntax:

// properties
var foo = {
    x: x,
    y: y,
    z: z,
}

// methods
var foo = {
    a: function() {},
    b: function() {}
}

Now here are ES6 equivalents:

// properties
var foo = {x, y, z}

// methods
var foo = {
    a() {},
    b() {}
}

Related to: #159

@mightyiam
Copy link
Member

I'd love this.

avoidQuotes

false, because minimalism? Although I don't remember writing such a function. avoidQuotes is relevant only to functions, isn't it? If I understand this correctly, then I'd say false. I have no problem with

{ 'foo-bar'() {} }

ignoreConstructors

Why is this a thing, please? I don't understand how in the example the rule can figure out that it's a constructor. It determines according to the name of the function, ConstructorFunction? Is it case detection?

And, again, why bother making it an exception at all?

avoidExplicitReturnArrows

I kinda like it. Yes... I'd say true. It kinda gets a bit too nit-picky compared to the rest of Standard, maybe. But why not? There are two ways of writing it and we can decide on one.

@LinusU
Copy link
Member

LinusU commented Apr 24, 2020

A lot of eco-system breakage, still think we should do this and mass send out PRs though, the rule is fixable.

  • always fail 75
  • properties fail 58

Maybe start with properties and upgrade to always later?

@LinusU
Copy link
Member

LinusU commented Apr 24, 2020

PR is up standard/eslint-config-standard#166

Just need to submit patches to all projects now 😄

@feross feross added this to the standard 17 milestone Nov 2, 2020
@feross
Copy link
Member Author

feross commented Nov 2, 2020

This seems like a potential candidate rule for standard 17. I expect we'd want to enable it as a "warning" for a full major version, becoming an error in 18. It's automatically fixable.

@feross
Copy link
Member Author

feross commented Nov 2, 2020

@standard/team Any feedback about this? @mcollina Any known performance issues related to this language feature?

@mcollina
Copy link

mcollina commented Nov 3, 2020

This is great to land, +1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

4 participants