ast-grep
ワークフロー
- ターゲットコードを表すテストスニペットを書く
- ルールを書く（
patternから始め、必要に応じてkind+has/insideに拡張する） - コードベースを検索する前に
--stdinでテストする - ルールがマッチしたらコードベースを検索する
重要な落とし穴
関係ルールでは常に stopBy: end を使用する
これがないと、has/inside は完全なサブツリーを走査せず、最初にマッチしないノードで停止します：
# 間違い — 深くネストされたマッチを見逃す
has:
pattern: await $EXPR
# 正しい
has:
pattern: await $EXPR
stopBy: end
シェルでメタ変数をエスケープする
$VAR はシェルによって解釈されます。エスケープするか、シングルクォートで囲んでください：
# ダブルクォート：バックスラッシュでエスケープ
ast-grep scan --inline-rules "id: test
language: javascript
rule:
pattern: await \$EXPR" .
# シングルクォート：エスケープ不要
ast-grep scan --inline-rules 'id: test
language: javascript
rule:
pattern: await $EXPR' .
メタ変数はASTノードの唯一の内容でなければならない
これらは機能しません：obj.on$EVENT、"Hello $WORLD"、a $OP b、$jq
名前のないノード（演算子、句読点）には $$OP を使用してください。0個以上のノードには $$$ARGS を使用してください。
--stdin によるテスト
echo "async function test() { await fetch(); }" | ast-grep scan --inline-rules 'id: test
language: javascript
rule:
kind: function_declaration
has:
pattern: await $EXPR
stopBy: end' --stdin
--debug-query によるデバッグ
ルールがマッチしない場合、ASTを調査して正しい kind 値を見つけてください：
ast-grep run --pattern 'your code here' --lang javascript --debug-query=cst
フォーマット：cst（全ノード）、ast（名前付きのみ）、pattern（ast-grep がパターンをどのように認識しているか）。
ルール構文
完全なルールリファレンス（アトミックルール、関係ルール、複合ルール、メタ変数）については references/rule_reference.md を参照してください。