[$50 Opire Bounty] feat(linter): eslint/no-invalid-regexp

[DonIsaac]

Implement ESLint's no-invalid-regexp rule.

To get started, run

just new-rule no-invalid-regexp

---

Bounty from @nabby27: https://app.opire.dev/issues/01HWTY9ZE1GM8XSS2QQGD84068

[ubugeeei]

Hi. To implement this rule, it seems necessary to implement a parser like @eslint-community/regexpp.

Where is this planned to be implemented?
If it's within this repository, please let me know where in the repository it should be implemented.

[Boshen]

Hi. To implement this rule, it seems necessary to implement a parser like @eslint-community/regexpp.

Where is this planned to be implemented? If it's within this repository, please let me know where in the repository it should be implemented.

We don't have a regex parser yet but it's open for contributions by veterans like you! If you are interested in learning Rust by implementing a regex parser, please reach out and I'll guide you. To get started, we have a small tutorial here where some of the chapters are already translated into Japanese 😁 https://oxc-project.github.io/javascript-parser-in-rust/ja/

[ubugeeei]

Oh, thank you for the detailed information.
I've also been busy with other things in the past few days, so it might take some time, but I'm thinking of trying to implement a prototype of the Rust rewrite of @eslint-community/regexpp in my repository.
I might propose integrating it somewhere at some point.

To get started, we have a small tutorial here where some of the chapters are already translated into Japanese 😁 https://oxc-project.github.io/javascript-parser-in-rust/ja/

The Japanese version is great! As a native speaker, I might be able to contribute to the translation into Japanese.

[ubugeeei]

Oops, I forgot to mention one thing.
I will try to implement the prototype, but if anyone reading this comment wants to work on this issue,
please don't hesitate to start. If your progress is faster, I will discard my project.
(Just because you've read this comment doesn't mean you need to stop your work.)

[Boshen]

Oops, I forgot to mention one thing. I will try to implement the prototype, but if anyone reading this comment wants to work on this issue, please don't hesitate to start. If your progress is faster, I will discard my project. (Just because you've read this comment doesn't mean you need to stop your work.)

No no, we can merge small pieces and collectively iterate on it so no effort is lost. Just send in small PRs. You may wish to try https://graphite.dev for such tasks.

[ubugeeei]

Thank you. For now, I'll give a small prototype a try.
Once I can see a roadmap of the smaller tasks I've broken down, I'll share it again!

You may wish to try https://graphite.dev/ for such tasks.

Oh, there's a tool like this? Thanks for introducing it to me. I didn't know about it, so I'll take a closer look!

[Maneren]

Hi, I tried coding a prototype regex parser some time ago in my fork. It can (afaik correctly) parse all regexes I found in the MDN docs. The main issues are imo the lack of a lexer (which would help with some backslash edge cases and string-vs-literal normalization) and messy output when dealing with unicode.

I temporarily gave up on it due to encountering too many small tedious issues (escaping, spans, output, ...) and then later also starting projects for school. I'd like to continue working on it in around two weeks, once I'll hopefully finish the schoolwork.

Feel free to either pick it up in the meantime or take inspiration for your version. I can clean it up tomorrow and possibly PR it in here.

(and sorry, I should have written somewhere earlier that I was working on it)

[ubugeeei]

I see. I didn't know that.
In that case, I'll refrain from implementing the prototype.
Let's prioritize and respect your achievements.

I have a suggestion: since you've made so much progress, why not create a feature branch in this repository for the regex-parser so everyone can collaborate there? And for issues related to this parser, it might be a good idea to leave documentation and address remaining concerns as separate issues. What do you think?
(I haven't looked closely at the Maneren branch, so I'm not sure if it can be integrated into oxc.)

In any case, it might be better not to have too many significant changes in the forked repository and merge them into the feature branch of this repository while sharing issues with everyone.

cc @Boshen

[ubugeeei]

At the very least, since this issue originally pertained to eslint/no-invalid-regexp, I've created a separate issue for the regular expression parser.
I would like to conduct discussions related to the parser here.
How do you feel about that proposal?

#1164

[Maneren]

I agree. Upon closer inspection (as in remembering what I did then) the branch can't be directly integrated to oxc since it also overwrites a linter rule for testing, making it unusable for now. Also the code structure isn't great as it was created hastily without preplanning and doesn't use existing oxc infra. That means we are probably better off starting from scratch, just reusing the parsing logic, which is imo ok.