Update: Add option "ignoreGlobals" to camelcase rule (fixes #11716)

[mcdado]

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

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

What changes did you make? (Give an overview)
Added an option to ignore global variables in the camelcase rule.

Is there anything you'd like reviewers to focus on?
Testing the change and add tests.

What rule do you want to change?
camelcase

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.)?
New option

Please provide some example code that this change will affect:

Examples of incorrect code for this rule with the default { "ignoreGlobals": false } option:

/*eslint camelcase: ["error", {ignoreGlobals: false}]*/
/* global some_property */

const property = some_property;

Examples of correct code for this rule with the { "ignoreGlobals": true } option:

/*eslint camelcase: ["error", {ignoreGlobals: true}]*/
/* global some_property */

const property = some_property;

What does the rule currently do for this code?
Returns an error.

What will the rule do after it's changed?
Offer an option to ignore the error.

[jsf-clabot]

All committers have signed the CLA.

[mightyiam]

I'm not a member of this project, but at the very least it seems that this requires a test.

[mcdado]

I'm not a member of this project, but at the very least it seems that this requires a test.

I could commit a broken test... I made a comment asking for input on how to achieve this, since I'm not familiar with the code base and I just tried to look around for hints. The committed code at the moment does not pass a test.

[kaicataldo]

Thanks for making this PR. This seems like a reasonable change to me, and I support this proposal.

Please note that this repository follows a process for accepting proposals and we won't be able to merge this until we have reached consensus within the team. We generally recommend making an issue to discuss design and implementation before making a PR, to save people time in case it doesn't get accepted. You can read more about this process here.

[mcdado]

Thanks for making this PR. This seems like a reasonable change to me, and I support this proposal.

Please note that this repository follows a process for accepting proposals and we won't be able to merge this until we have reached consensus within the team. We generally recommend making an issue to discuss design and implementation before making a PR, to save people time in case it doesn't get accepted. You can read more about this process here.

Thanks. I had found #11716 but I was interested and motivated enough to make this happen. I hope this can go through. :)

[mcdado]

This world be nice to merge 😉

[kaicataldo]

@eslint/eslint-team We need a champion and one more 👍 to accept this proposal. If not, it's probably time to close this PR.

[mdjermanovic]

I'm willing to champion this. This is a new option in a stylistic rule, but I personally think it's more a bug fix than an enhancement.

[nzakas]

Okay I’ll 👍 to put it over the top. @mdjermanovic can you review this PR?

[mdjermanovic]

Thanks for the changes! This looks good, just two minor notes.

[mdjermanovic]

LGTM, thanks!

[kaicataldo]

Thanks for contributing!