Prettierの深淵：ASTハックによる「整形エンジン」の支配とコード品質の完全統制
多くのエンジニアにとって、Prettierは「設定ファイルに従ってコードを機械的に並べるだけのブラックボックス」でしかない。しかし、我々アーキテクトにとって、Prettierは「ソースコードのAST（抽象構文木）を自在に再構築するための強力なトランスパイルエンジン」に他ならない。
既存の`// prettier-ignore`だけでは、ドメイン駆動設計（DDD）における複雑なデータ構造や、パフォーマンスを追求した密な計算式、あるいは特定のドメイン特有のDSL表現を保護・制御するには力不足だ。本稿では、Prettierの内部アーキテクチャを突き破り、独自のコメント・アノテーションで整形ルールを動的に制御する「ASTハック」の極意を伝授する。
—
1. ASTハックの核心：Prettierプラグインによるノード・インターセプト
Prettierは、コードを解析してASTを生成し、それを再帰的に辿って`Doc`と呼ばれる中間表現に変換、最終的に文字列として出力する。我々が介入すべきは、この「ASTからDocへの変換プロセス」である。
カスタムプラグインを構築し、特定のコメント（例：`// @preserve-layout`）をトリガーにして、特定のASTノードのプリント処理をフックする。
// prettier-plugin-custom-layout.js
module.exports = {
printers: {
estree: {
print(path, options, print) {
const node = path.getValue();
// 1. ノードに特定のアノテーションコメントが存在するかチェック
if (hasCustomAnnotation(node, ‘@preserve-layout’)) {
// 2. ASTのソースから元のコードを直接抜き出し、整形エンジンをバイパスする
return options.originalText.slice(node.start, node.end);
}
// 通常のフローに戻す
return null;
},
},
},
};
このアプローチの真価は、「特定のコードブロックだけをPrettierの支配下から解放しつつ、型安全性はESLintで担保する」というハイブリッドな運用を可能にする点にある。
—
2. CI/CDパイプラインへの統合：動的アノテーションの検証
単純にプラグインを入れるだけでは不十分だ。開発者が「誤ったアノテーション」を乱用するのを防ぐため、CIパイプラインの初期フェーズでASTを静的解析し、アノテーションの正当性を担保するカスタムスクリプトを走らせる。
CIパイプラインのアーキテクチャ（GitHub Actions例）
jobs:
lint-and-format:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: AST Integrity Check
# Prettierを実行する前に、独自アノテーションが適切に使用されているかを検査
run: node scripts/validate-ast-annotations.js –path ./src
- name: Prettier Execution
run: npx prettier –write . –plugin ./prettier-plugin-custom-layout.js
`validate-ast-annotations.js`では、`@typescript-eslint/parser`を使用してASTを走査し、`@preserve-layout`が許可されたスコープ以外で使用されていないか、あるいはブロックが巨大すぎないかを厳格にチェックする。これにより、コードベースの「整形の一貫性」と「例外的な表現の自由」を両立させる。
—
3. パフォーマンス最適化：メモリ消費とキャッシュの制御
Prettierのプラグイン開発において最も見落とされがちなのが、AST走査時のメモリオーバーヘッドである。特に大規模なモノレポ環境では、全ファイルをAST化するとNode.jsのヒープメモリを圧迫し、ビルド時間が線形的に増大する。
- `–cache` オプションの深掘り:
Prettierのキャッシュはファイルハッシュに基づくが、カスタムプラグインを追加した場合、プラグインの変更をキャッシュキーに含める必要がある。CI環境では環境変数でプラグインのバージョンをハッシュ化し、`PRETTIER_CACHE_KEY`として利用せよ。
- Worker Poolの活用:
`prettier`はデフォルトでシングルスレッドだが、`worker_threads`を併用したラッパーを書くことで、大規模なコードベースにおいて並列整形を実現できる。
—
4. 現場で震えるほど役立つ知見：なぜこの制御が必要か
なぜ、ここまで面倒なことをするのか。それは「機械的な整形と、人間の意図的な可読性の衝突を避けるため」である。
例えば、線形代数の行列演算や、最適化されたビット演算のコードは、整形エンジンによって崩されると「数学的な直感」が消失する。我々が求めているのは、コードの「見た目」を揃えることではなく、「コードが持つ構造的・数学的な意味」を、機械的な整形から守り抜くことだ。
この技術をマスターした者は、チームのコーディング規約に「逃げ道」を論理的に実装できる。強制力だけの画一的なプロジェクトから脱却し、「高パフォーマンスを維持するための意図的な混沌」を許容する高度なアーキテクチャへ昇華させよ。
結びに代えて
PrettierのAPIをハックすることは、単なるツールへの追従ではない。それは、コードの生成プロセスを自身の支配下に置く、エンジニアとしての「越境」である。次にあなたがコードを整形する時、そのASTの裏側で何が起きているのかを想像してほしい。その想像力こそが、卓越したエンジニアと、単なるオペレーターを分かつ境界線となる。