Consistent object destructuring spacing

[dcousens]

Is it possible a rule could be added for the following cases:

var { x} = ...  // ERROR: Inconsistent spacing
var {x } = ...  // ERROR: Inconsistent spacing
var { x } = ... // OK (1)
var {x} = ... // OK (2)

Extra options (though less important for my case) could also be to allow strict enforcement over option 1 or option 2 ONLY.

If such a rule already exists, my apologies.

[nzakas]

I believe object-curly-spacing should cover this case: http://eslint.org/docs/rules/object-curly-spacing

[feross]

@nzakas object-curly-spacing forces to you pick one style var {x} = ... or var { x } = ....

I believe @dcousens is asking for an option to allow either style, while preventing the use of inconsistent spacing like var { x} = ... or var {x } = ....

[xjamundx]

So the proposal is a new option on http://eslint.org/docs/rules/object-curly-spacing#options to be "either"?

[dcousens]

@xjamundx yes, this would allow us to enforce consistency in an otherwise ambiguous environment where currently anything goes.

[nzakas]

Out of curiosity, why not just pick one style?

[dcousens]

@nzakas semver.
This would classify as a patch for existing wrong behaviour, but previously we hadn't set the rule as to whether there should be a space or not.

We intend to enforce one eventually, but right now, it would break too much code (as standard is used for tests).

[mysticatea]

The rule is off by default?
Only when you turn the rule on by yourself, it warns your code.

[dcousens]

@mysticatea I was referring to standard's versioning, not eslint.
This would be a patch for standard, if we enforced one or the other, it would be a breaking change.

[nzakas]

@dcousens it sounds like you're asking us to implement a change that you only intend to use temporarily so as not to require a major version bump for standard right now. I don't think that's a good reason for us to make such a change.

[dcousens]

@nzakas I don't think that is true, as the end result is that we may not enforce 1 style XOR** the other.

We want to enforce consistent spacing throughout standard, in either style, for an indeterminate amount of time, and this is the best way we can do that.

I know this change would also be beneficial for other projects I work on where we want consistency, but also do not enforce 1 style or the other (and nor do those projects use standard).

[lo1tuma]

ESLint could only enforce consistency within a file. If you don't pick one style you might end with inconsistent styles across all project files.

[mysticatea]

We can choose turn the rule on/off each project.

[dcousens]

@lo1tuma I'd rather see { x } and {x}, consistently, than "anything goes" inconsistently.
I didn't mean only 1 style consistently, I meant both.

The end result [may be] that we may don't enforce 1 style XOR** the other.

[nzakas]

@dcousens we generally don't have rules that allow two styles at the same time, as this typically is too confusing for users.

Unless someone on the ESLint team wants to champion this change, I'm leaning towards encouraging you to create a custom rule.

[dcousens]

Thanks @nzakas, it won't be ideal for us, but I understand where you are coming from.

@feross shall I close?

[feross]

Sure, I think that's totally fair.
On Mon, Jul 13, 2015 at 6:48 PM Daniel Cousens notifications@github.com
wrote:

Thanks @nzakas https://github.com/nzakas.

@feross https://github.com/feross shall I close?

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

[xjamundx]

@dcousens, @feross if you want help making a plugin to add this functionality, let me know. it shouldn't be too hard!

[feross]

@xjamundx yes, that would be a great help! want to move the discussion over to standard/standard#182 ?