rule change proposal: destructured properties to be non-camelcased with camelcase rule

Hi eslint team! I’ve filled out the questions from https://github.com/eslint/eslint/blob/master/templates/rule-change-proposal.md but please let me know if you’d like any more detail here. I’m happy to work on a PR myself if this sounds like a sensible approach.

What rule do you want to change?

The camelcase rule.

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

Fewer.

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

A new option:

"camelcase": [ "error", { "ignoreDestructuring": false }]
"camelcase": [ "error", { "ignoreDestructuring": true }]

Please provide some example code that this change will affect:

const { foo_bar } = baz;

What does the rule currently do for this code?

The rule currently always fails for these expressions (with or without the properties: "never" config option set).

See related discussion in #3185 and #9715

What will the rule do after it’s changed?

If the "ignoreDestructuring": true option is set, the line of code above should pass the rule (while the rule should still be enforced for other identifiers in the source).

[alunny-stripe]

Mostly, I think const { foo_bar: fooBar } = baz is harder to read and noisier.

One case that also comes up a lot in the app I work on is somebody picking off properties from object (perhaps from a remote api) in order to use rest destructuring - I don’t think this code:

const {some_property, some_other_one, ...rest} = remoteObject;
// do something with rest

is improved by:

const {some_property: someProperty, some_other_one: someOtherOne, ...rest} = remoteObject;
// do something with rest

or

/* eslint-disable camelcase */
const {some_property, some_other_one, ...rest} = remoteObject;
/* eslint-enable camelcase */
// do something with rest

It’s also useful for object shorthand, when you’re taking some remote data that has snake cased property names and using that for a subsequent request - for example:

  getIframeURL() {
    const {title, some_other_param} = this.props;
    const queryParams = qs.stringify({
      title,
      some_other_param,
    });
    return `${IFRAME_URL}?${queryParams}`;
  }

without modifying the rule this becomes:

  getIframeURL() {
    const {title, some_other_param: someOtherParam} = this.props;
    const queryParams = qs.stringify({
      title,
      some_other_param: someOtherParam,
    });
    return `${IFRAME_URL}?${queryParams}`;
  }

which is just more typing, and no more readable or maintainable.

[platinumazure]

I’m a bit confused by the proposed option values. What does “always” or “never” mean: allow always/never, or warn always/never? I would much prefer something like ignoreDestructuring: true (or false) to make it more clear exactly what the configuration means.