Allow escaping `/` inside regex character groups

Tell us about your environment

• ESLint Version: 4.12.1
• Node Version: 9.2.0
• npm Version: No npm

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

Please show your full configuration:

Configuration

env:
  es6: true
  node: true
extends: 'eslint:recommended'
# parser: babel-eslint
parserOptions:
  sourceType: module
rules:
  indent:
    - off
  linebreak-style:
    - error
    - unix
  quotes:
    - error
    - single
  semi:
    - error
    - never
  no-console:
    - off
  no-unused-vars:
    - warn
    - varsIgnorePattern: ^_
      argsIgnorePattern: ^_

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

const re = /https:\/\/github\.com\/([^\/]+)\/(.*)/
console.log(re)

# via neomake

What did you expect to happen?

It passes without warnings.

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

Unnecessary escape character: \/. (no-useless-escape) (E)

---

As I said previously, this one is annoying. Linters are expected to help coding, not make it harder.

• There is nothing wrong to escape that /. And it will make some people think it’s wrong if you don’t because they don’t know they can put unescaped / there.
• It makes writing regexes harder. It’s much simpler to remember to escape every / in a regex literal than noticing that you don’t need to escape ones inside character groups.
• You can’t grab a simple (and compatible with the JS one) regex somewhere else and put it in a regex literal by escaping every /. You can’t even copy & paste regexes from nodejs’s output because the pretty-printer escapes them.
• Syntax highlighters may not get it right (e.g. vim-es7 doesn’t). They need to be fixed but we can be nicer to them.

I don’t think that escape is useless. It’s useless for JS engines, but it’s useful for people to read and write. It’s unlike escapes like /\a/ which is usually unwanted (intended to match the bell character but matches a instead).

The / is special because it’s the delimiting character in JS regex literals. Not all regexes come this way. I don’t think it’s part of the regex syntax but the regex literal syntax (you don’t need to escape it in a new RegExp constructor, like you need to escape ' in 'I\'m' but not in "I'm"). If you get a raw string and want to put it in a string literal, escape every ' and \ and quote it with '. If you get a raw regex and want to put it in a regex literal, it’ll be nice if you escape every / and \ and quote it with / and get no warnings.

I’m not proposing any other changes about no-useless-escape. It has been helpful for a while and only this particular case annoys me.

[ilyavolodin]

I think there’s a lot of other cases where escape is unnecessary (and will be reported), but wouldn’t change the outcome of the RegEx. For example escaping control character inside a character class doesn’t hurt the outcome, but will be flagged by the rule, because it will work correctly without escaping. I’m not sure I see the difference in this case either. The rule is design to report unnecessary escapes that can safely be removed without affecting the outcome. That’s also the case with the example you provided. So, from my perspective, the rule is doing it’s job correctly.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.