feat: add a proof-of-concept eslint plugin

[mikavilpas]

Note: this is only a draft, a proof-of-concept designed to be a basis for discussion

How would you feel about adding some parjs specific eslint rules? I think there might be some use cases for this.

Here I have implemented a super simple rule which warns that the .debug() method should not be included in code (not good to have it in production code as it's a development time feature).

Here are some other ideas for rules:

• could optionally require top level parser variables to have an .expects("") call to make debugging easier
• could encourage using many1 instead of many(...) -> exactly(1)
• could encourage simplifying string("a").pipe(...).pipe(...) to string("a").pipe(..., ...) (unnecessary pipes)

There may be more ideas that I couldn't think of.

---

I don't have experience writing eslint rules, but it looks like this way of writing the rules is pretty basic; more powerful than regular expressions but nowhere close to understanding the code on a deep level.

It's pretty easy to "cheat" the rules by writing code in a way that doesn't trigger the rule - for example storing the .debug method reference in a variable and calling it later.

However, I think the rules could still be useful even though it seems they are quite naive.

The proof-of-concept rule in this PR would need some improvements, such as:

• could probably write them in typescript instead of javascript. I just followed the basic tutorial in the eslint docs without putting in too much effort
• testing could be done in jest
• not sure if the yarn workspace setup is correct, but it did seem to work :)

[mikavilpas]

Looks like the build is now failing because of the rule I added.

Ahem, this was totally intentional as it also serves as a demo 😄

[GregRos]

This is a wonderful idea! I feel like a parser combinator library is something you write in, rather than use, so it makes sense for there to be an eslint plugin.

Sorry for the very late reply. Had real life stuff happen in great quantities. The situation here is still pretty unstable politically, and besides that there was a possibility of me getting fired. Things seem to have stabilized in their instability, at least for the moment.

I do have a lot of ideas though. I'm working on a v2, though because I have so many ideas it will probably take a while. I'll push stuff once to a branch once it's cohesive enough so you can have a look. I'm looking at major changes to the API, though I have some ideas to make the transition easier. Mainly the stuff I described back in February.

In the near future (hopefully today) I'm going to transition this repo to a monorepo format together with the char-info package, so it will be a nice place to put such a plugin as well.

[mikavilpas]

Sounds exciting! I would say let's keep this open as a draft since there isn't that much code.

Once the new ideas stabilize somewhat, we can take a new look at how this might fit into the project.

I'm looking at major changes to the API, though I have some ideas to make the transition easier. Mainly the stuff I described back in February.

Yeah I read the stuff and learned a lot reading it. I feel like it's a good direction to go to. I'll be happy to take a deeper look later and throw some ideas around with you.

[GregRos]

Apologies, I didn't manage to finish the monorepo refactor. I've gotten lost and am now on an insane attempt to make React on top of Tkinter, while learning Python along the way.

This other insane project is kind of limited, though, and soon I'll get back the working on this.

[GregRos]

Okay I'm back again. I finished the weird React thing I was working on.

It involved applying React as an abstract designed pattern to a different UI framework. It turned out to be quite a lot more work than I'd thought. Oh, also politics happened to me and now I don't have a job, but that's unrelated.

I am back to working on this though.