no-useless-escape: Special case for RexExp literal character sets.

What rule do you want to change? no-useless-escape

Likely related to pull-request #7425.

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

How will the change be implemented? (New option, new default behavior, etc.)? There’s a special case for regular expression literals that might be worth excepting from this rule: escaping an opening-square-bracket character [ that is used within a character set.

This ends up being a bit confusing due to asymmetry. A [ does not need to be escaped but a ] must be escaped.

I suspect most developers would escape in this situation, by default, so making it the default behavior might be best and should not make any existing code that was lint-free linty.

An option could be provided to restore absolute strictness, for the machines among us.

Please provide some example code that this change will affect: I came across the following in an older code-base that is integrating ESLint into its build process. It’s a character set that happens to be matching square-brackets.

name = name.replace(/[\[\]]/g, "\\$&");

What does the rule currently do for this code? It flags \[ as being a useless escape. While this is true (it still works fine when left unescaped), what ESLint would prefer, /[[\]]/g, is more difficult for a human to parse at first glance (not to say the original is cakewalk).

What will the rule do after it’s changed? It would quietly permit the escape of opening-square-brackets within character sets in regular expression literals. The escape is useless from a syntactical perspective, but it is not useless from a legibility perspective.

Are you willing to submit a pull request to implement this change? I have not yet investigated how difficult the change would be to make and the time investment required. I can only say, “perhaps”.

[mdjermanovic]

Hi @JHawkley, thanks for the enhancement proposal!

I think this is a reasonable request, but new default behavior as proposed looks to me like a breaking change since this isn’t a bug.

I’d vote for an option in this rule: an array of allowed characters.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.