For @alex__bit and ast-grep developpers.
I am aware that I have not yet done enough research and learning about ast-grep. But I will summarize what I have been thinking.
I am prototyping a tool called typescript-mcp that provides IDE refactoring functions using MCP. I am also developing an LSP version that is TypeScript-independent.
https://github.com/mizchi/typescript-mcp
This allows me to provide semantic functions equivalent to rename, goToDefinition, and findReferenecs.
(I have confirmed that the function works, but the prompts that prioritize its use in LLM are not yet complete.)
There are several uses I have been thinking of for ast-grep/tree-sitter/oxc/riggrep.
Giving MCP LSP functions was effective after I had repeatedly edited the code to a certain extent and had a better understanding of the code.
Looking at the behavior of RooCode and ClaudeCode, when you first give instructions in natural language, they perform fuzzy grep with queries that seem to match the instructions.
This does not distinguish between definition sources, references, and comments. Because the queries are highly flexible, what is found by the first query will not be reproducible in subsequent tasks.
It is common to perform static analysis and indexing by scope, like GitHub Agents' #codebase, but indexing for each editing step is inefficient.
So, if we want responsiveness and versatility, we need a sufficiently fast AST scan and semantic analysis from it. I think that ast-grep and tree-sitter (oxc_parser/oxc_linter if limited to +typescript) are candidates.
However, ast-grep does not have type-checker capabilities (right?). I go through LSP because I need scope analysis and definition source information.
It may be enough to just give a mechanical pattern, thinking of it as a pre-scan in advance.
My main job is a freelancer who renovates the front-end. I spend a month at various companies improving the speed of their CI build pipelines or Lighthouse.
Recently I have migrated from jest to vitest and from cypress to playwright.
Going from vest to vitest was pretty mechanical, but going from cypress to playwright seemed difficult with a simple replacement.
For example, if I can automatically generate a generalized ast-grep correction query for a patch edit unit created manually (or infer an ast-grep query using a model), I think it might be possible to generalize it to other projects.
(japanese)
まだ ast-grep について調査と学習が足りてないのを自覚しています。が、一旦考えていたことを洗い出しておきます。
私は typescript-mcp というMCP で IDE のリファクタリング機能を提供するツールを試作しています。また、この発展形でTypeScript非依存なLSP版を作っています。
これによって、 rename, goToDefinition, findReferenecs 相当のセマンティックな機能を提供することができています。
(機能としては動くことは確認していますが、LLMにその使用を優先させるプロンプトがまだ不完全です)
私が ast-grep/tree-sitter/oxc/riggrep の用途で考えていたものはいくつかあります。
MCPにLSPの機能を与えて有効だったのは、ある程度コード編集を繰り返してコードに対する理解が高まったあとです。
RooCode やClaudeCodeの挙動を見ていると、最初に自然言語で指示を与えたとき、それに該当しそうなクエリでファジーな grep を行います。
これは定義元や参照、コメントを区別しません。クエリの自由度が高いので、最初のクエリによってみつかるものその後のタスクの再現性がなくなります。
GitHub Agents の #codebase のように静的解析してスコープごとのインデクシングを行っておくのは最近よくある手法ですが、編集ステップごとにインデクシングを行うのは非効率です。
なので応答性と汎用性を求めると、十分に高速なASTのスキャン、そこから意味解析が必要なのではないか？と考えています。そこで ast-grep と tree-sitter (+typescript に限定するとoxc_parser/oxc_linter)が候補になっています。
ただ、 ast-grep は type-checker の能力を持ちません(よね？)。私がLSPを経由してるのはスコープ解析や定義元の情報が必要だからです。
事前のプレスキャンと割り切って、機械的なパターンを与えるだけで十分かもしれません。
私は本業はフロントエンド改修のフリーランスです。様々な会社に一ヶ月だけ入り、CIのビルドパイプライン、または Lighthouse をターゲットに速度改善行います。
最近 jest から vitest, cypress から playwright という移行を行いました。 vest から vitest はかなり機械的でしたが、 cypress -> playwright は単純な置換では難しいように感じました。
例えば、手作業で作成した patch の編集単位において、それに対応する一般化した ast-grep の修正クエリを事後的に自動生成(またはモデルによる ast-grep のクエリの推論)ができれば、それが別プロジェクトへの一般化出来るのではないか？と考えています。
Hi, ast-grep author here. Thanks for the questions. Let me address them one by one
ast-grep is a langauge agnostic tool. but type checking is highly language dependent. While it is impossible to integrate type checking builtin, it is possible to use https://microsoft.github.io/language-server-protocol/specifications/lsif/0.4.0/specification/ and range rule to query pre-built type index. That said, LSIF is read only so it cannot update type info when editing.
Yes, you can try using this AI model https://app.codemod.com/studio for mechanical migration. Or use ast-grep mcp to find code, then ask AI to migrate code one by one.