Introduce "ignoreForSingleProperty" value for prefer-destructuring

What rule do you want to change? prefer-destructuring

Does this change cause the rule to produce more or fewer warnings? if configured, fewer; otherwise no change

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

Please provide some example code that this change will affect:

Web Extension here:

browser.storage.sync.get("popupIconColored").then((res) => {
    const popupIconColored = res.popupIconColored;

    // …
});

(real-life example)

What does the rule currently do for this code? When prefer-destructuring is enabled, it complains that I should use destructuring here. So I’d have to use this:

const { popupIconColored } = res;

(not tested, it also has been mentioned I may have to put brackets around that even more…)

What will the rule do after it’s changed?

It should not complain about the previous code example.

I would like a config option named “smart” or similar, so that the rule only catches cases, where destructuring “makes sense” (hereby I mean that I access multiple values of an array/object of it directly) and not, when I only access one value and want a short variable name for that.

This example e.g. makes sense and should still be catched with the smart setting:

function getFullName(user) {
  const firstName = user.firstName;
  const lastName = user.lastName;

  return `${firstName} ${lastName}`;
}

Because here, I assign/get two variables from the object. However, when I only want to get one variable, destructuring just complicates the code IMHO.

In short: Add an option, which only triggers when I get multiple values from an array/object and not only a single one.

[ljharb]

No, that’s the “AssignmentExpression” option.

enforceForRenamedProperties is for controlling whether you allow const foo = obj.bar or whether you require it to be const { bar: foo } = obj;.

[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.