Apply escape-case to regex literal and remove transformation of \c escape on string literal

[JLHwung]

This PR addresses issue and feature request in #273. I've made separate commit on this.

Although the owner suggested using https://github.com/mysticatea/regexpp, I decide not to use it for performance considerations -- There would be many regular expression in a mature codebase and we can not afford the extra regular expression parse + replace cycle only to find whether there is any escapable sequence.

The original escapeWithLowercase pattern should work good enough on regular expression under most situation. I have minimally modified the code to support slightly difference escape syntax between string literal and RegExp literal/objects.

Fixes #273

[futpib]

A slightly off-topic nitpick.

Although the owner suggested using mysticatea/regexpp, I decide not to use it for performance considerations -- There would be many regular expression in a mature codebase and we can not afford the extra regular expression parse + replace cycle only to find whether there is any escapable sequence.

Would it really be that slow? We could eventually cache the result and reuse it in other regexp-related rules (or maybe even across projects). Even if it were substantially slower, we may value correctness and maintainability over speed, especially for a linter (unless it was really slow).

Also a mature codebase with a lot of unique regular expressions sounds like a nightmare.

I'm not saying this PR should not be accepted, only that the argument against regexpp is not convincing.

[MrHen]

I agree with @futpib. Performance issues should be addressed once they have been confirmed. Does the slower approach add 0.5 seconds for every 1,000 regex statements? 1 minute for every 10 regex statements?

[JLHwung]

we may value correctness and maintainability over speed, especially for a linter (unless it was really slow).

Make sense, I can spare some time to try on the regexpp approach.

[JLHwung]

@futpib Upgraded the branch. The new lowercase detection approach is

1. use regexpp to parse regular expression literal
2. tap on onCharacterLeave handler, check if it is the first occurrence of escaped lowercase sequence
3. report if invalid

The fixer approach is

1. use regexpp to parse regular expression literal
2. tap on onCharacterLeave handler, check if it is the first occurrence of lowercase sequence, record the position of escaped sequence in the regular expression
3. replace the original escaped sequence with the one applied with the string escape fixer
4. return the replaced string as the fixed regular expression literal

[sindresorhus]

@JLHwung Can you give the PR a proper title that describes what it fixes?

[sindresorhus]

I pushed some minor formatting tweaks: 38f91bb

[sindresorhus]

You cannot use .start and .end. See: #272

[JLHwung]

Here is different to fixer.replaceTextRange([node.start, node.end]) as the node here is actually the ASTNode from regexpp, while other node is the AST node from eslint parsers.

As start and end is official properties of a ASTNode in regexpp, I think we can leave it as-is, but I can add a comment here as a reminder.

[sindresorhus]

Ah ok. I missed that. It's ok to leave it. My mistake.

[sindresorhus]

Use replaceText(node instead of replaceTextRange[node.start, node.end]

[sindresorhus]

I would prefer returning undefined instead of null.

[JLHwung]

Thanks for the review comments. I am sorry that I am taking vacation off my laptop for a couple days. I will come back and revise on the next week. Thank you.

[JLHwung]

Regards to the feedback, I have pushed fixes and they are ready to review.

[sindresorhus]

Thanks for working on this, @JLHwung 🙌