Make prefer-destructuring fixable

[golopot]

What rule do you want to change?
prefer-destructuring

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

Please provide some example code that this change will affect:

// This
const z = a.z
// should autofix to this
const { z } = a

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

[kaicataldo]

This seems like a reasonable enhancement to me, however I do wonder what the autofixing behavior should be for array destructuring when the index > 0. i.e. should it autofix const foo = bar[2]; to const [,, foo] = bar;?

[ljharb]

I think it probably shouldn’t autofix in that case - since it’s iterable destructuring, not array destructuring, and there’s no guarantee that an object with a 2 property is either an array or iterable.

[bendtherules]

Few cases I could think of :

1. Handling just assignments: z = a.z
   1.a. Make sure that solution ({z} = a); is wrapped in parenthesis to make valid expression
2. Longer assignment expressions: blah = z = a.z (which is different from blah = {z} = a)
3. Merging different property names from same object ??

// from
let x = a.x;
let y = a.y;
let z = a.z;

// to
let {x, y, z} = a;

// Merging with nesting ??
// from
let x = a.x;
let y = a.something.y;
let z = a.something.z;

// to
let {x, something: {y, z}} = a;

This would be very very hard to implement correctly, but produce more human-like result.

[platinumazure]

What about nested destructuring cases, in addition to the cases above?

My thinking is, this would be a pretty significant implementation and maintenance burden, unless we only cover very simple cases and just don't bother with the rest. I'm currently mildly opposed to this for that reason, but could be persuaded.

[sindresorhus]

I would be happy if it only auto-fixed the simple case, like let x = a.x; => let {x} = a;.

[eslint-deprecated]

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.

[ilyavolodin]

I think supporting auto-fixing for the most basic cases is fine for this rule.