本番運用への道
Vize は、まだ実験段階です。
これは、逃げ道としての但し書きではありません。現在の段階をそのまま説明したものです。
目標は、実験的なプロジェクトから、本番で使えるツールチェーンへ進むことです。そのための誠実な道はひとつしかありません。実際のプロジェクトでの検証と、コミュニティからのフィードバックです。
小さなサンプルアプリでは足りない
小さなサンプルは、開発の役に立ちます。
ひとつのルール、ひとつの変換、ひとつのソースマップ、ひとつのコンパイラの動作だけを切り出して確認できます。
しかし、本番の Vue プロジェクトは小さなサンプルではありません。次のようなものが含まれています。
- 変わったパッケージ構成
- 新旧の Vue の書き方の混在
- パスエイリアス
- 自動インポート
- マクロ
- スタイルのプリプロセッサ
- 深くネストしたコンポーネント
- 生成されたファイル
- フレームワークの規約
- プラグインの挙動
- プラットフォーム固有の問題
小さなサンプルにしか通らないツールチェーンは、本番で使えるとは言えません。
それは、見栄えのよいデモが付いたプロトタイプです。
徹底した総当たりが効く
ここで最も重要なのは、地味な作業です。
Vize は、実際のプロジェクトを、ファイルひとつずつ、エラーひとつずつ、診断ひとつずつ、スナップショットひとつずつ確認していく必要があります。
確認する対象は、次のとおりです。
- ビルドの出力
- lint の出力
- 型チェックの出力
- フォーマッタの安定性
- ソース上の位置
- パスの解決
- 開発サーバーの挙動
- 本番ビルドの挙動
- Windows と Unix の違い
こうした総当たりの作業に、華やかさはありません。
しかし、「サンプルでは動く」を「実際のリポジトリでも持ちこたえる」に変えるのは、この作業です。
コミュニティからのフィードバックを開発の手がかりにする
コミュニティは、メンテナーが想像もしなかったケースを見つけてくれます。
それは失敗ではありません。それこそが狙いです。
実際の報告は、どれも貴重です。
- コンパイルに失敗するプロジェクト
- ルールを使い物にならなくする偽陽性
- 技術的には正しいが、役に立たない診断
- CI で急激に性能が落ちるケース
- 対応できていないマクロの規約
- Windows でだけ起きるパスの問題
- トークン 1 つ分ずれた位置を指すソースマップ
こうした報告は、作業の邪魔ではありません。データセットそのものです。
正しい対応は、それらをフィクスチャ、テスト、スナップショット、ベンチマークに変えることです。
「本番で使える」は、ラベルではなく振る舞い
「本番で使える」という状態は、README にそう書いたから実現するものではありません。
時間をかけて示される、次のような振る舞いのことです。
- 不具合報告が、回帰テストになる
- ベンチマークが、実際のワークフローを対象にしている
- リリースノートが、リスクを説明している
- 破壊的な変更が、意図したものである
- CI が、サポートするプラットフォームを反映している
- 診断が、自動化に使えるだけ安定している
- ツールが何をするのかを、利用者が予測できる
Vize は多くの層に関わるため、これはとくに重要です。コンパイラの食い違い、リンターの偽陽性、型チェックの食い違い、誤ったソースマップは、それぞれ別の形で信頼を損ないます。
対象とする範囲が広いぶん、求められる水準も高くなります。
独立していることの利点
公式のツールには、別の種類の慎重さが求められます。
エコシステムからの期待を、すぐに背負うことになるからです。多くの利用者に影響を与えずに、大胆な実験をすることはできません。
Vize は独立しているので、素早く動く余地があります。
- アーキテクチャの変更を試す
- 内部を書き直す
- 厳格な診断を追加する
- 別のコンパイラバックエンドを試す
- 弱い抽象化を取り除く
- 性能のボトルネックを追いかける
- すぐに安定させると約束せずに、コミュニティの報告から学ぶ
この速さは役に立ちますが、責任も伴います。
プロジェクトは、自分の現在地をはっきり示し、検証に真剣に取り組まなければなりません。
ロードマップは、フィードバックが形づくる
本番で使えるようになるまでの道のりは、機能のチェックリストだけではありません。
フィードバックのループです。
- 実際のプロジェクトで Vize を実行する。
- 失敗をすべて、テストかフィクスチャとして残す。
- 症状だけでなく、根本にあるモデルを直す。
- 公式のツールと動作を比較する。
- 性能を見える状態に保つ。
- 意外なケースが当たり前のケースになるまで、繰り返す。
ツールチェーンは、そうやって成熟していきます。
完成したふりをすることによってではありません。
実際のコード、実際の利用者、実際の制約に作業を形づくってもらい、信頼できるものになるまで続けることによってです。