Update: optionally allow bitwise operators (fixes #4742)

[Swaagie]

Mostly useful for allowing the NOT operator for code like ~[1, 2, 3].indexOf(1), which is something where using bitwise operators makes sense. I know there are no docs attached, but mainly was wondering if these kinds of features get accepted.

Usage would be along the line of no-bitwise: [2, { allow: [ '~' ] }]

edit: clean new PR from #4738
edit: related to #4742

[gyandeeps]

How about isOperatorAllowed as the name of the function? Then pass in the operator as the argument to his function. Its more readable IMO.

[Swaagie]

Decided to stick with the method signature already present in this rule, but if you feel strong about it I don't mind changing.

[gyandeeps]

Please update:

• Documentation of the rule with the new option.
• Also update the rule schema to reflect the new option.

[gyandeeps]

@btmills In the above case, option schema was not updated with the new option. I thought the unit test would fail in this case as the schema is not correct. Am i missing something here?

[btmills]

Good catch, @gyandeeps - that's a bug. I'll open an issue once I've diagnosed it further. It shouldn't block this PR - we just need to make sure the schema gets updated before we merge. As long as it's not [], the tests will catch any problems with it.

[Swaagie]

Good catch totally forgot about the docs, will add

[Swaagie]

Not sure about the schema, is there any task/command I can trigger to test if the schema's get updated or not?

[btmills]

It should be something like this. As long as the schema isn't [], it'll be validated as part of the tests.

module.exports.schema = [
    {
        "type": "object",
        "properties": {
            "allow": {
                "type": "array",
                "items": {
                    "enum": ["^", "|", "&", "<<", ">>", ">>>", "^=", "|=", "&=", "<<=", ">>=", ">>>=", "~"]
                },
                "uniqueItems": true
            }
        },
        "additionalProperties": false
    }
]

[Swaagie]

Added the schema, tests all run fine.

[michaelficarra]

For anyone reading this PR and not paying attention to the original issue, please hold off on merging until my concerns there are addressed. I think this is entirely the wrong approach.

[indexzero]

+1 on this. This is one of the major "gotchas" that block many folks from switching from JSHint to ESLint. In JSHint the no-bitwise: true rule is equivalent to no-bitwise: [2, { allow: [ '~' ] }] in ESLint.

@michaelficarra after reading through #4742 it is clear that you disagree with this approach. That is noted. If you have an alternative approach you would like to suggest a PR speaks much more strongly than comments.

@nzakas @gyandeeps are we good here? I'd love to see this land. It's one of the last gotchas for more widespread ESLint adoption at GoDaddy because we switched from JSHint.

[nzakas]

Yeah, I think this is good to go. There haven't been any other proposals and I still feel this is a good solution.

[indexzero]

Thanks @nzakas. Happy New Year! 💯

[Swaagie]

Thanks for merging this :)