warning of unnecessary / accidental escape character in string literal

[KnickdaKnife]

var host="thebother";
var matchlist="exactly.this ^(:?this|that|the\.other)$".split(" ");
if (host===matchlist[0] || new RegExp(matchlist[1]).test(host)) { return true; } else { return false; }

Desired outcome = /^(:?this|that|the\.other)$/.test("thebother"). Which does not match because we are missing the literal dot from "the.other".

Unfortunately the code does not function as intended, because the \. is treated as an escape when defining the string literal, and so the actual RegExp used becomes /^(:?this|that|the.other)$/.test("thebother"). This little bug went undetected for some months (as it does match all the expected values, and testing didn't cover this particular unmatched value).

Feature Request is that when JSHint processes string literal it WARNS of unnecessary escape character usage so as to alert the developer to unintended / accidental inclusion of the escape character (when the intention might have been to have a literal \ rather than to escape the character that follows).

So recognised single escape sequences would not produce the warning but \ NonEscapeCharacter (http://es5.github.io/x7.html#x7.8.4) would produce a warning.

in my case, use of JSHint to check my code would warn of the presence of \. - and I'd have corrected the bug with \\. rather sooner.

[jugglinmike]

I like this idea! We should probably apply it to template literals and regular expression literals, too (although the character sets are slightly different in each context).

When it comes to regular expression literals, folks in an ES6-enabled environment can opt-in to this restriction thanks to the u flag:

// ES6-compliant runtimes tolerate the following unnecessary escape:
/\j/;

// ES6-complaint runtimes reject the following unnecessary escape:
/\j/u;

That behavior's part of the language, so it'll cause a syntax error today, anywhere. It's worth noting that JSHint implements that behavior because it gives us a head start on this feature request.

$ echo '/* jshint esversion: 6 */ void /\j/u;' | ./bin/jshint --verbose -
stdin: line 1, col 32, Invalid regular expression. (E016)

1 error

There may even be an opportunity to re-use some of that code...

Anyway, to preserve backwards compatibility, we'll have to implement this as a so-called "enforcing option" (that is: the behavior will have to be opt-in via a new linting rule).

I'm happy to assist anyone who wanted to write a patch for this. @KnickdaKnife since you suggested it, you get first dibs :) Let me know if you're interested!