RFC: Biome Plugins Proposalを読む
mehm8128GritQL
ドキュメント翻訳したときにちょっと触ったので雰囲気は知ってる
console.log("Hello world!");
だったり、
`$path && $path()` => `$path?.()`
のようなクエリを使うことでソースコードにマッチさせたり、マッチしたコードに変換処理を施したりできるやつ
ESLintのルール作るときみたいに、AST見て「これがExpressionStatementだからなんたら～」みたいな書き方をするのではないので、クエリを書くやり方でどこまでできるのかがかなり気になってる
ast-grepとかとの比較も書かれてる
「GritQL in Biome」のセクションでは、実際にnoImplicitBooleanのルールをGritQLを使ってどのように実装できるかの例が書かれている
このくらいのルールなら確かにこのくらいで書けるけど、複雑なルールのときに同じように書けるのかな
mehm8128JS/TS plugins
GritQLではなくてJS/TSを用いたプラグインの作成方法。この場合はASTを見て色々する
一番の問題はパフォーマンス。Biomeはそもそもパフォーマンスが1番の売りなので、パフォーマンスが低下するようなものは避けたいとのこと
JS/TSで書かれたものでも、人気のあるプラグインはRust化して本体に統合される可能性もあるらしい
「Linter API」のセクションでさっきのnoImplicitBooleanを、今度はJSで実装した例が書かれている
JsxAttributeというASTに入ったときの処理を書いていることが分かる
「Transformation API」セクション
JSでAST見て分岐すると複雑になる場合に、JSからGritQLのクエリを呼び出すことできる。この場合Rust側で実行してくれるので、パフォーマンス的にもいいらしい。さらに、JSからクエリを呼び出しているので部分的にJSも使いつつGritQLも使いつつみたいなことができるらしい？
But meanwhile developers writing their own rules or transformations still have the full flexibility of JavaScript available in processing the matches.
mehm8128Choice of Engine
エンジンの話詳しくないのでパスで
mehm8128GritQLでどこまでできるのか？という話はここでGritQLの作者が説明してくれてそう
https://github.com/biomejs/biome/discussions/1762#discussioncomment-8404136
ドキュメント見てみた感じ、ASTでマッチすることもできるっぽい
mehm8128GritQLのformatterサポートがされるのって、「JS/TS plugins」で見たみたいにgrit関数にGritQLを渡せるようにするからformatできると便利そうみたいな理由なのかな
mehm8128簡単なルールであればGritQLの方が簡単に書けそうだけど、逆に既存のルールをGritQLで書くようにしたりってしないのかな