feat: add options to check destructuring in no-underscore-dangle

[Kaltoft]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[x] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What rule do you want to change?
no-underscore-dangle

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

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

Please provide some example code that this change will affect:

const [foo, _bar] = list;
const [foo, ..._rest] = list;
const [foo, [bar_, baz]] = list;
const { foo, bar: _bar } = collection;
const { foo, bar, _baz } = collection;

What does the rule currently do for this code?
Currently variable names assigned from destructuring arrays and objects are not handled

What will the rule do after it's changed?
Handles variable names assigned from destructuring arrays and objects

What changes did you make? (Give an overview)

• Added an optional check variable names from array destructuring toggled by { allowInArrayDestructuring: true }
• Added an optional check variable names from object destructuring toggled by { allowInObjectDestructuring: true }

Is there anything you'd like reviewers to focus on?

Variables assigned from deep destructuring and the ...rest pattern

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Kaltoft / name: Morten Kaltoft (1e3319a, c934788, d2c4247, 7aca753, ad2c3fe, dd49fef, 4cee4e2)

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	08c8030
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/62f10d33f598020008a47761

[btmills]

Thanks for catching this omission, @Kaltoft! I'm 👍 to fixing this.

It looks like no-underscore-dangle doesn't check object destructuring either (demo). Would you be up for adding that as well?

As-is, this is a breaking change because it reports new errors on existing code. Usually, when we add additional checks to rules, we create an option as you've done here, but we default it to match the existing behavior. Then we can toggle the default to on in the next major release if we think it's something that fits with the theme of the rule.

Questions for the team to move forward:

1. Should no-underscore-dangle check array destructuring patterns? 👍 from me.
2. Should it also check object destructuring patterns? 👍 from me.
3. If we say yes to both, should we have one option (currently allowDestructured: true) or two (e.g. allowInArrayDestructuring: true and allowInObjectDestructuring: true)? I'd say two separate options.

[Kaltoft]

It looks like no-underscore-dangle doesn't check object destructuring either (demo). Would you be up for adding that as well?

Good point. I'll take a look at it.

If we say yes to both, should we have one option (currently allowDestructured: true) or two (e.g. allowInArrayDestructuring: true and allowInObjectDestructuring: true)? I'd say two separate options.

Personally I think splitting them into separate options is preferred since the use-case for destructured names in arrays is often quite different to that in objects.

[Kaltoft]

I've updated the PR to check for variables names from object destructuring as well.

The default value for both options are now set to true, following @btmills advice and to not introduce any breaking changes. My suggestion would be to set the default to false for next major release, as I see this as expected behaviour.

[btmills]

Thanks for making those changes! The implementation and existing tests look good. In addition to my two comments on the diff, will you please sign our CLA?

[Kaltoft]

CLA signed and all tests passing 👌

[Kaltoft]

Thank you @mdjermanovic I've updated the PR to address the issues you mentioned.

[github-actions]

Oops! It looks like we lost track of this pull request. What do we want to do here? This pull request will auto-close in 7 days without an update.

[Kaltoft]

Oops! It looks like we lost track of this pull request. What do we want to do here? This pull request will auto-close in 7 days without an update.

@mdjermanovic @btmills could you check this again? Everything should be ready

[mdjermanovic]

I'll close & reopen just to re-run checks.

[mdjermanovic]

@Kaltoft apologies for the long delay in reviewing this PR.

LGTM, thanks for contributing!