feat(linter)!: parse and display syntax errors for regular expressions

[Boshen]

cc @leaysgur shipping to production!

This is marked as breaking change because there may be false positives.

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[graphite-app]

Merge activity

• Aug 26, 1:23 AM EDT: The merge label 'merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Aug 26, 1:23 AM EDT: Boshen added this pull request to the Graphite merge queue.
• Aug 26, 1:26 AM EDT: Boshen merged this pull request with the Graphite merge queue.

[codspeed-hq]

CodSpeed Performance Report

Merging #5214 will not alter performance

_{Comparing linter-regex (5946748) with main (2fbc283)}

Summary

✅ 29 untouched benchmarks

[leaysgur]

NOTE: As I commented somewhere (sorry, I forgot), this means that invalid regexp literal will be reported in the parser stage.

Still some lint rules like eslint/no-invalid-regex can report error for regexp constructor usage, but not for literal(= never reports).

[Boshen]

It conforms to the spec if the regex parser throws a syntax error for /regex/ syntax, everything else should go into a linter 😅

[leaysgur]

I also think it is natural. Early errors are good. 🙂‍↕️