GritQL integration progress (April 24)

[arendjr]

Exactly three weeks ago, I wrote about my progress integrating GritQL into Biome. Back then there was a major technical challenge to overcome: GritQL heavily relies on TreeSitter for parsing the code it needs to operate on. In Biome, we have our own parsing infrastructure, so we'd like it if those TreeSitter-dependencies are optional instead.

Current State

Yesterday I reached an important milestone, since I created a PR to extract the grit-core-patterns crate out of the core Grit engine. This new crate is entirely free of TreeSitter dependencies, and can serve as a starting point for creating a new Grit engine on top of Biome's infrastructure.

Of course, creating a new engine for Biome means there is still quite a lot of work ahead of us. After all, grit-core-patterns only represents a subset of the functionality that was found in the Grit engine. The parts we couldn't extract will need to be reimplemented for Biome. Still, I'm hopeful we can reach some more very interesting milestones in the near future.

Some things to consider:

• Even though we cannot reuse all code from Grit's engine, those other parts are still open-source. This means those parts can serve as a reference, and we don't need to start entirely from scratch for Biome. Some of the parts of the Biome engine may be more akin to a porting effort than a full reimplementation.
• GritQL has a lot of advanced features, and the Grit engine has a lot of code dedicated to supporting those advanced use cases. But Biome has no backwards compatibility concerns in this regard, which means we can start with a very narrow feature set and expand from there.

Next Steps

As I've mentioned before, the short term goal is to create a biome search command that can search files in a Biome project for any matches of a given Grit pattern. This command will initially be very narrow in scope:

• It will not support rewrites.
• It won't support the Grit standard library.
• It won't support multi-file patterns.

That doesn't mean Biome will never support those things, of course. Hopefully one day our engine will be advanced enough to support the standard library, and I think that should include multi-file patterns as well. I imagine we'll create a dedicated command that will support rewrites down the line. But by keeping the initial scope small, we'll hopefully have something cool to show sooner rather than later.

Another consideration is that the biome search command doesn't need to support every advanced use case for us to use its abilities as a stepping stone towards our plugin efforts. After all, that's why we started this adventure in the first place :)

But before I will return to the biome search command, I will focus on implementing the Biome bindings to the GritQL engine. With these bindings in place, Biome should have a rudimentary matching engine in place which the biome search command can invoke. I have created an umbrella issue to track this work: #2582

Help Wanted

I'm grateful to mention we have a volunteer on board willing to help with the output formatting for the biome search command, shoutout @BackupMiles! But as you can see, there's a lot of work ahead of us still, so more volunteers are always welcome! Also, we can still use helping hands implementing JavaScript plugins or a GritQL formatter too.

If you're interested in helping out, feel free to have a look at the umbrella issue for Biome plugin support or reach out to us on the #plugins channel on our Discord.

Of course, feel free to ask questions in the comments here as well!

Cheers!