Prettierの深淵へ：自作DSLを美しく操る「カスタムプリンタ」実装の極意
多くのエンジニアにとって、Prettierは「設定ファイル一つでコードを揃えてくれる魔法の箱」でしょう。しかし、社内独自のドメイン特化言語（DSL）や、複雑なメタプログラミングを駆使した巨大なライブラリを開発している際、Prettierのデフォルト動作が「逆に読みづらさを助長する」というジレンマに直面したことはありませんか？
本稿では、PrettierのプラグインAPIをハックし、抽象構文木（AST）を操作して、独自の構文を「人間が読みやすい形」に強制整形する、極めて実戦的なテクニックを伝授します。
—
1. なぜPrettierプラグインを書く必要があるのか
大規模なTSプロジェクトでは、独自のデコレータや、複雑な関数チェーン（Fluent Interface）が頻出します。これらを標準のPrettierに任せると、改行が不自然に入ったり、ネストが深すぎてコードの意図が隠蔽されたりします。
真のテックリードは、ツールに人間を合わせるのではなく、「チームが最も生産的に読めるコードの形」をツールに定義させます。 それがカスタムプラグインの存在意義です。
—
2. 実戦的アーキテクチャ：ASTからPrinterへの橋渡し
Prettierプラグインの心臓部は `print` 関数です。これはASTの各ノードを受け取り、Prettier独自の「Doc」という中間表現を生成する関数です。
基本的なプラグイン構造
`prettier-plugin-custom-dsl.js`
module.exports = {
languages: [{
name: “CustomDSL”,
parsers: [“custom-parser”],
}],
parsers: {
“custom-parser”: {
parse: (text) => {
// ここで自作のパーサー(Babelやacorn等)を呼び出しASTを生成
return ast;
},
astFormat: “custom-ast”
}
},
printers: {
“custom-ast”: {
print(path, options, print) {
const node = path.getValue();
// 独自のノードタイプ「MyCustomNode」を検知して整形ルールを注入
if (node.type === “MyCustomNode”) {
return [“CustomLogic(“, path.call(print, “expression”), “)”];
}
return print(path); // それ以外は標準のプリントに委譲
}
}
}
};
ここがプロの勘所: `path.call(print, “expression”)` を使うことで、子ノードの再帰的な整形をPrettierのエンジンに任せつつ、親の枠組みだけを制御できます。全てを自分で書こうとせず、「制御したい部分だけをフックする」のが長期メンテナンスの鉄則です。
—
3. チーム開発を加速させる「神」設定と運用ルール
プラグインを入れるだけでは不十分です。チーム全体の生産性を極限まで高めるための構成を紹介します。
.prettierrc.yaml のベストプラクティス
JSONではなくYAMLを採用し、コメントで「なぜこの設定なのか」を明記します。
チーム開発におけるイデオロギーをここに集約
printWidth: 100 # 現代のワイドディスプレイでは80は短すぎる
tabWidth: 2
semi: true
singleQuote: true
trailingComma: all # Gitの差分を最小限にするための黄金律
独自プラグインの有効化（ローカル開発時はnpm linkで開発）
plugins:
- “./plugins/prettier-plugin-custom-dsl.js”
特定のディレクトリは強制的に除外
overrides:
- files: “src/generated//”
options:
printWidth: 200 # 生成コードは読みやすさより解析のしやすさを優先
—
4. 開発効率を「秒」単位で改善する小技
隠れたキーボードショートカット
- `Shift + Alt + F` (VSCode): これを叩くのが習慣になっていないなら、即座に「保存時フォーマット」設定を有効化してください。思考のコンテキストスイッチを物理的に遮断します。
- `Ctrl + .` (Quick Fix): ESLintと組み合わせた際、エラーを無視するのか、自動修正するのかの判断を瞬時に行うために必須です。
絶対に入れるべき補助ツール
1. `eslint-plugin-prettier`:
PrettierのルールをESLintの警告として表示させます。フォーマットエラーを「静的解析の不備」として扱うことで、CIで確実に弾けるようになります。
2. `prettier-plugin-sort-imports`:
import文の順序を強制します。`node_modules`、外部ライブラリ、自作ライブラリ、相対パスの順に並べることで、コードの依存関係を視覚的に即座に把握できます。
—
5. 最後に：テックリードからの提言
コードの整形は単なる「見た目」の問題ではありません。「コードが予測可能であること」は、脳の負荷を劇的に下げます。
今回解説したカスタムプラグインの作成は、最初はコストに見合うか不安になるかもしれません。しかし、チームが「なぜか読みづらいコード」の解読に費やす時間を、一日に5分減らせるとしたら？ 10人のチームで年間数十万円分の価値を生み出します。
まずは、あなたのプロジェクトで最も「整形が乱れやすく、理解に時間がかかる部分」を特定し、そこだけに絞った小さなプラグインから書き始めてみてください。それが、最強のエンジニアリング・チームへの第一歩です。