Do not detect features in comments

[AlfonzAlfonz]

This is mostly a draft and I'm more than happy to make any adjustments/fixes. Newer versions of es-check (and fast-brake) are matching language features in comments, which means that a valid es5 code will be marked as invalid. This is very easy to encounter, because /** is considered an exponentiation operator.

Comments should to be replaced with whitespace, so their content won't get matched, but it keeps all other code at the same location. This is similar to "Strip types only" option in swc.

Similar approach should be also taken for strings because var x = "() => {}"; will get matched as well

[yowainwright]

@AlfonzAlfonz looking forward to looking at this!

[yowainwright]

@AlfonzAlfonz this is great start! Thank you for this!
We need to implement something similar to https://github.com/jonschlinkert/strip-comments
Do you want to work on this? 🙇

[AlfonzAlfonz]

@yowainwright Yes, I would like to. I've went through ES5 and this should be for comments, string and for regular expressions. That should address most of the false positives. I will implement simple parser, which will replace content of all of those expression. From what I've read this should be mostly straightforward for strings/comments, but it may be more difficult for regexes.

There is still more work to be done, because this PR focuses on ES5, which does not support syntax such as template literal. Also this won't address false positives in identifier names.

var x = `() => undefined`

var let_const = 5;

// this is valid ES5 code in non-strict mode
var let = 3;

Those are mostly edge cases and I would say that they are out of scope of this PR.

[AlfonzAlfonz]

I think the code should be ready for review, in the end I've wrote a simple parser, which transforms strings and comments into empty whitespace. I've decided not to implement the same mechanism for regular expressions, because it's impossible to detect what's a regular expression without parsing the code.

// this is regular expression
var x = 5 + / x /
4;

// this is not regular expression
var x = 5 / x / 
4;

Both examples are syntactically valid pieces of code, but mean something else.

I don't think it is possible to detect language features reliably without parsing the code. I think the ideal route is to find potentially problematic code, erase other code and then parse only the code which could be problematic. I think that would keep it fast, while giving accurate results.