The camelcase rule does not allow leading/trailing underscores for variable names

[KylePDavis]

Tell us about your environment

• ESLint Version: v4.13.0
• Node Version: v8.9.3
• npm Version: v5.5.1

What parser (default, Babel-ESLint, etc.) are you using?
default

Please show your full configuration:

Configuration

{
    "parserOptions": {
        "ecmaVersion": 8,
        "sourceType": "module",
        "ecmaFeatures": {}
    },
    "rules": {
        "camelcase": 2
    },
    "env": {}
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

Contents of test.js:

function shouldAllowUndercoreVars() {
	let { _value } = this;
	return _value;
}
shouldAllowUndercoreVars()

Shell command used:

eslint test.js

This is currently reproducible on the eslint demo site:
https://eslint.org/demo/#eyJ0ZXh0IjoiZnVuY3Rpb24gc2hvdWxkQWxsb3dVbmRlcmNvcmVWYXJzKCkge1xuXHRsZXQgeyBfdmFsdWUgfSA9IHRoaXM7XG5cdHJldHVybiBfdmFsdWU7XG59XG5zaG91bGRBbGxvd1VuZGVyY29yZVZhcnMoKSIsIm9wdGlvbnMiOnsicGFyc2VyT3B0aW9ucyI6eyJlY21hVmVyc2lvbiI6OCwic291cmNlVHlwZSI6Im1vZHVsZSIsImVjbWFGZWF0dXJlcyI6e319LCJydWxlcyI6eyJjYW1lbGNhc2UiOjJ9LCJlbnYiOnt9fX0=

What did you expect to happen?
I would have expected it to allow the variable name based on the camelcase docs docs quoted below:

It ignores leading and trailing underscores and only checks those in the middle of a variable name.

What actually happened? Please include the actual, raw output from ESLint.

/Users/kyle/tmp/test.js
  2:8  error  Identifier '_value' is not in camel case  camelcase

✖ 1 problem (1 error, 0 warnings)

[platinumazure]

Agreed, this seems to only apply to destructuring however.

No lint errors:

const _value = true;

Has lint errors (incorrectly):

const { _value } = obj;

@KylePDavis Does this occur in 4.12.x for you? Wondering if this was a side-effect of #9468.

[platinumazure]

Applying "patch candidate" label because the original change intentionally added more warnings, but the change actually added even more warnings than anticipated.

[guyellis]

@platinumazure I think you've got this but if you need more info this is a greenkeeper/travis combo showing the fail from 4.12.1 to 4.13.0:
https://travis-ci.org/guyellis/plant/builds/313796790

Your PR LGTM. Is there an easy way for me to test your branch/PR against my repo?

[platinumazure]

If you changed your package.json to point at my commit or branch (see NPM docs for details), you could push that to a branch (presumably something other than your master branch) and let Travis run against that to see if all is well. (This assumes you have the ability to push branches to your GitHub. If not, you could just make the change locally and run your tests locally as well.) Hope this helps!

…

On Dec 8, 2017 10:12 PM, "Guy Ellis" ***@***.***> wrote: @platinumazure <https://github.com/platinumazure> I think you've got this but if you need more info this is a greenkeeper/travis combo showing the fail from 4.12.1 to 4.13.0: https://travis-ci.org/guyellis/plant/builds/313796790 Your PR LGTM. Is there an easy way for me to test your branch/PR against my repo? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9700 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARWekTl2M85b1rHGFMBOMoC-GyUH-Yhks5s-gingaJpZM4Q7yaT> .

[guyellis]

Thanks @platinumazure
I referenced this in package.json:

"eslint": "git@github.com:eslint/eslint.git#camelcase-destructuring-leading-trailing",

And that fixes the linting in my project. Thanks.

[platinumazure]

I'm hoping the team agrees that this should justify a patch release; if so, that patch release will probably occur sometime on Monday. Thanks for your patience and thank you also for testing the change!

[KylePDavis]

Thanks for the speedy response. The fix works great!