なぜ「自分たちの言語」をPrettierに握らせるのか：アーキテクチャの視点
多くのエンジニアは、ESLintとPrettierを「コードの見た目を揃える道具」として消費している。しかし、真のテックリードにとって、Prettierは「プロジェクト固有のDSLや独自仕様の言語を、チームの共通言語へと昇華させるための強力な抽象化エンジン」である。
もし君のプロジェクトで、設定ファイルや社内独自クエリ、あるいはカスタムDSLを人力でフォーマットしているなら、それは技術的負債の芽だ。Prettierのプラグインシステムを使いこなすことは、単なる「見た目の統一」を超え、開発者が「構文の正しさ」という認知負荷から解放され、ビジネスロジックの構築に全脳を割けるようにするための戦略的投資である。
—
1. Prettierプラグイン開発の核心：AST解析からPrinter実装まで
Prettierのプラグイン開発は、大きく分けて「Parser（解析）」と「Printer（出力）」の二つのコンポーネントを設計することに集約される。
AST（抽象構文木）への変換
まず、対象言語をPrettierが理解できるASTに変換する必要がある。ここで重要なのは、「位置情報（loc）」を完璧に保つことだ。これがないと、Prettierが後に続くコメントや空白をどこに挿入すべきか判断できず、フォーマットの崩壊を招く。
Printerインターフェースの魔法
PrettierのPrinterは、ASTノードを再帰的に巡回し、独自の「Doc」という中間言語に変換する。
- `concat`: 文字列を結合する。
- `group`: 柔軟な折り返しルールを定義する単位。
- `indent`: 改行時のネストを自動管理する。
以下のコードは、独自DSLをフォーマットするための基本骨子である。
// prettier-plugin-my-dsl.js
const print = (path, options, print) => {
const node = path.getValue();
switch (node.type) {
case ‘Assignment’:
// ‘group’を使うことで、長すぎる場合にのみ改行する「賢い」折り返しが可能になる
return group(concat([
path.call(print, ‘left’),
‘ = ‘,
indent(concat([softline, path.call(print, ‘right’)]))
]));
// ここにASTの各ノードに対する再帰的なルールを実装していく
}
};
プロの知見： 既存言語（SQLやGraphQLなど）を拡張したい場合は、`prettier`をラップし、`originalText`をいじってから標準パーサーに渡す「ラッパー・アプローチ」が最も堅牢だ。車輪の再発明は避け、既存のパーサーを最大限に再利用せよ。
—
2. チーム開発を加速させる「神設定」と運用ルール
プラグインを自作したとしても、チームの環境がバラバラでは意味がない。以下の構成は、大規模開発の現場で「設定の不一致」を完全に排除するベストプラクティスだ。
`.prettierrc` の集約と継承
プロジェクト直下に置くだけでなく、共有パッケージ（`@company/prettier-config`）として切り出し、npm/yarnで管理することを推奨する。
{
“$schema”: “https://json.schemastore.org/prettierrc”, // VSCodeで補完を効かせるために必須
“plugins”: [“./prettier-plugin-my-dsl”], // 独自プラグインのパス
“semi”: true, // 議論の余地をなくすために強制
“trailingComma”: “all”, // git diffを最小化する絶対ルール
“printWidth”: 100, // 近年の高解像度ディスプレイに適した幅
“overrides”: [
{
“files”: “.my-dsl”,
“options”: { “tabWidth”: 2 } // 拡張子単位での厳密な制御
}
]
}
—
3. 開発スピードを極限まで引き上げる「隠しコマンド」
エンジニアが「フォーマット」という概念を意識すること自体がコストである。以下のフローを導入せよ。
1. `format-on-save` の限界と `lint-staged`
VSCodeの `editor.formatOnSave` は素晴らしいが、大規模レポジトリでは全ファイルフォーマットが走ると激重になる。必ず `lint-staged` を使い、コミット直前の差分ファイルにのみ適用すること。
// package.json
“lint-staged”: {
“.{js,ts,my-dsl}”: [
“eslint –fix”, // 静的解析と整形をセットで実行
“prettier –write”
]
}
2. 神ショートカット：`Shift + Alt + F` の先へ
フォーマットを「手動でやる作業」から「環境が勝手にやる作業」へ昇華させるために、以下の設定を `settings.json` に追加せよ。
// VSCode設定: 保存時の自動整形を「選択的」かつ「高速」にする
“[javascript][typescript][my-dsl]”: {
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
“editor.formatOnSave”: true
}
—
アーキテクトからの提言：なぜここまでやるのか
Prettierのプラグイン開発や厳格なCI/CD設定は、単なる「こだわり」ではない。「コードの書き方にまつわる議論（タブかスペースか、どこで改行するか等）を、組織の意思決定プロセスから永久に排除する」ための、極めて合理的なエンジニアリングである。
人間は、動くコードそのものの品質を議論すべきだ。ASTを解析し、コードの構造を自動的に整える仕組みを自ら構築した時、君のチームは初めて「記述の揺れ」という低次元の悩みから解放され、アーキテクチャの真の課題に向き合えるようになる。
さあ、次は君がその独自DSLをPrettierの力で美しく制御する番だ。それは、君のプロジェクトに「一貫性」という名の最強の武器を授けることになるだろう。