Vize
ツールチェーンを垂直統合する利点
近年の開発ツールでは、役割を細かく分ける設計がよく選ばれます。
コンパイルには、専用のパッケージ。 lint には、別のパッケージ。 フォーマットには、さらに別のもの。 型チェックにも、専用のもの。 コンポーネントのドキュメントにも、専用のもの。 エディター支援にも、専用のもの。
この考え方には理由があります。小さなツールは公開しやすく、交換しやすく、役割も説明しやすいからです。
一方で、別の捉え方もできます。
個々のユーティリティを集めるのではなく、ツールチェーンとして設計するという考え方です。
その視点では、垂直統合は必要以上に範囲を広げることではなく、つながっている処理を整理するための方法になります。
ここでいう垂直統合とは
ここでいう垂直統合は、同じ開発ワークフローの中で、つながりのある複数の層をまとめて設計することです。
- 構文解析
- 意味解析
- コンパイル
- lint
- フォーマット
- 型チェック
- 言語ツール
- ランタイムやバンドラーとの統合
ツールが単に並んでいるだけでなく、共通の基盤で同じプログラムを理解するように設計します。
この違いは、思った以上に大きなものです。
利点 1：プログラムの理解を揃えられる
処理が分かれたツール群の問題は、速度だけではありません。 ツールごとに、コードの理解が食い違うことです。
多くの場合、それぞれのツールは、独自に次のものを持ちます。
- パーサー
- AST
- 設定モデル
- スコープの扱い
- フレームワークの意味を近似する方法
同じファイルを処理しているはずなのに、実際には異なるモデルとして理解していることになります。
垂直統合は、こうした食い違いを減らせます。
コンパイル、lint、フォーマット、型チェックを同じコード構造のモデルから行えば、次のことが期待できます。
- 矛盾を減らせる
- 特殊なケースでの挙動の違いを減らせる
- 重複する処理を減らせる
- 診断の挙動を予測しやすくなる
ツールチェーン全体の一貫性が高まります。
一貫して使えることは、開発ツールの大切な品質の 1 つです。
利点 2：同じ処理を何度も繰り返さずに済む
処理が分かれたツールチェーンでは、同じファイルを何度も解析することがあります。
- コンパイルのために 1 回
- lint のために 1 回
- フォーマットのために 1 回
- 型チェックのために 1 回
- エディターの中でもう 1 回
同じ作業を、そのまま繰り返していることになります。
同じ構文を何度も読み取る。 同じ関係を何度も見つける。 同じフレームワークの意味を何度も組み立てる。
垂直統合されたツールチェーンでは、その処理結果を層をまたいで共有できます。
- 1 つのパーサーを複数のツールで使う
- 1 つの AST から複数の出力を作る
- 1 回の意味解析を複数の診断に使う
- 1 つのファイルモデルを CLI とエディターで共有する
速度の改善に加えて、アーキテクチャも整理しやすくなります。
利点 3：開発中のフィードバックを揃えられる
開発ツールは、最終的な出力を作るだけでなく、作業中に情報を返します。
各層がつながっていれば、それぞれが持つ情報を他の層にも活かせます。
- コンパイラの知識を、エディター支援に活かす
- 意味解析の結果を、lint に活かす
- 型情報を、テンプレートの診断に活かす
- フレームワークの構造を考慮してフォーマットする
- エディターと CLI で、同じ理解に基づく結果を返す
ツールチェーンを、コマンドの寄せ集めではなく、1 つの道具として使えるようになります。
診断が揃う。 エディターと CLI の結果が一致する。 修正内容に納得できる。 速さを得るために、設計と無理に折り合いをつけずに済む。
そうした一貫性は、使っていて感じられるものです。
利点 4：利用者が覚えることを減らせる
ツールが別々に分かれていると、それぞれの仕組みを理解する必要があります。
- どの設定ファイルが、何を制御するのか
- どのツールが、どの警告を出しているのか
- どのパーサーと変換処理の理解が食い違うのか
- どのプラグインが、フレームワークのどの特殊な挙動に対応するのか
これは、フロントエンド開発で見えにくい負担になっています。
垂直統合は、その負担を減らせます。
複雑さそのものがなくなるのではなく、利用者に任せていた部分を、ツールの内部で扱えるようにするためです。
これも、開発体験を改善する大切な点です。
よいツールチェーンは機能を提供するだけでなく、利用者に代わって、付随する複雑さを引き受けます。
利点 5：AI 支援の基盤を揃えられる
この考え方は、AI 支援にもつながります。
基盤となるツールが、コードを一貫した決定論的な方法で理解できれば、AI もその情報を利用できます。層ごとに同じファイルを別々に理解していると、その食い違いは AI が利用する情報にも持ち込まれます。
共通の基盤があれば、AI は次の情報を揃えて扱えます。
- コード構造の情報源
- コードの意味を扱う情報源
- 診断の情報源
- 修正候補の情報源
自動化が進むだけでなく、結果を信頼しやすくなります。
設計の美しさとは
主観的だと捉えられやすい話ですが、私は設計の美しさも大切だと思っています。
よいツールチェーンは、役立つだけでなく、美しさを感じられることがあります。
ブランドやスクリーンショットの見た目ではなく、次のような設計のことです。
- 少数の明確な考え方で成り立つ
- 部品どうしの関係が分かりやすい
- 不要な重複がない
- 意図しない矛盾がない
- それぞれの部分が、自然に組み合わさっている
フォーマッター、リンター、コンパイラ、エディター支援が、同じ対象を異なる側面から扱っていると感じられるツールチェーンには、美しさがあります。
装飾としての美しさではなく、設計が対象の構造を素直に表していることから生まれる美しさです。
汎用ツールを組み合わせることにも価値がある
垂直統合が、常に正しい答えになるわけではありません。
組み合わせて使えるツールにも強みがあります。 フレームワークに依存しない基盤も重要です。 Vite+ や Oxc のような汎用のエコシステムには、大きな価値があります。
多くの場合、すべてを置き換える必要はありません。
- 汎用の基盤は、得意なツールを組み合わせて使う
- フレームワーク固有の処理は、一貫性を高められる部分で統合する
Vize についても、そのように考えています。
Vue 固有の処理をまとめるために、周辺のエコシステムを否定する必要はありません。汎用ツールと協力しながら、Vue を扱う部分では統合の利点を活かせます。
Vue でこの考え方が役立つ理由
.vue ファイルには複数の層があるため、Vue はツールチェーン全体を考えるのに向いています。
- テンプレートの構文
- スクリプトのロジック
- スタイルブロック
- SFC の規約
- それらの層にまたがる、フレームワーク固有の意味
各部分を別々のツールに任せ、つながりが薄いままだと、ファイル全体の理解が分かれてしまいます。
Vue ツールチェーンを垂直統合すれば、次のことを目指せます。
- SFC を 1 つの単位として理解する
- 各層を意図して連携させる
- コンパイラ、リンター、フォーマッター、型チェッカーの理解を揃える
速度だけでなく、コードの捉え方そのものを改善する取り組みです。
私が垂直統合に美しさを感じる理由
各部分の関係を、設計にそのまま表せることに惹かれます。
パーサーとコンパイラはつながっています。 コンパイラと診断もつながっています。 診断とエディター支援もつながっています。 エディター支援と AI 支援もつながっています。
意識するかどうかにかかわらず、これらの関係は存在します。
別々のツールで構成する場合、その関係がアダプター、プラグイン、ラッパー、重複した基盤の裏に隠れることがあります。 ツールチェーンとして設計すれば、関係そのものを直接モデル化できます。
私は、その素直さに美しさを感じます。
構造が見える建築のように、各部分がなぜ存在し、他の部分をどう支えているかが分かるからです。
Vize に惹かれる理由
これも、Vize を魅力的に感じる理由の 1 つです。
すべての層が完成しているからではありません。 垂直統合が簡単だからでもありません。 1 つのプロジェクトですべてを持つべきだという考えでもありません。
次の設計に、可能性を感じています。
- 1 つのパーサー
- 1 つの AST
- Vue ファイルについての共通の理解
- その基盤から作る複数のツール
このようなツールチェーンは、速く、使いやすく、設計を理解しやすいものにできるかもしれません。
うまく設計できれば、美しさも備えられます。
偶然ではなく、設計の各部分が整合していることから生まれる美しさです。