Vize

本番運用への道

Vize は、まだ実験段階です。

これは、逃げ道としての但し書きではありません。現在の段階をそのまま説明したものです。

目標は、実験的なプロジェクトから、本番で使えるツールチェーンへ進むことです。そのための誠実な道はひとつしかありません。実際のプロジェクトでの検証と、コミュニティからのフィードバックです。

小さなサンプルアプリでは足りない

小さなサンプルは、開発の役に立ちます。

ひとつのルール、ひとつの変換、ひとつのソースマップ、ひとつのコンパイラの動作だけを切り出して確認できます。

しかし、本番の Vue プロジェクトは小さなサンプルではありません。次のようなものが含まれています。

  • 変わったパッケージ構成
  • 新旧の Vue の書き方の混在
  • パスエイリアス
  • 自動インポート
  • マクロ
  • スタイルのプリプロセッサ
  • 深くネストしたコンポーネント
  • 生成されたファイル
  • フレームワークの規約
  • プラグインの挙動
  • プラットフォーム固有の問題

小さなサンプルにしか通らないツールチェーンは、本番で使えるとは言えません。

それは、見栄えのよいデモが付いたプロトタイプです。

徹底した総当たりが効く

ここで最も重要なのは、地味な作業です。

Vize は、実際のプロジェクトを、ファイルひとつずつ、エラーひとつずつ、診断ひとつずつ、スナップショットひとつずつ確認していく必要があります。

確認する対象は、次のとおりです。

  • ビルドの出力
  • lint の出力
  • 型チェックの出力
  • フォーマッタの安定性
  • ソース上の位置
  • パスの解決
  • 開発サーバーの挙動
  • 本番ビルドの挙動
  • Windows と Unix の違い

こうした総当たりの作業に、華やかさはありません。

しかし、「サンプルでは動く」を「実際のリポジトリでも持ちこたえる」に変えるのは、この作業です。

コミュニティからのフィードバックを開発の手がかりにする

コミュニティは、メンテナーが想像もしなかったケースを見つけてくれます。

それは失敗ではありません。それこそが狙いです。

実際の報告は、どれも貴重です。

  • コンパイルに失敗するプロジェクト
  • ルールを使い物にならなくする偽陽性
  • 技術的には正しいが、役に立たない診断
  • CI で急激に性能が落ちるケース
  • 対応できていないマクロの規約
  • Windows でだけ起きるパスの問題
  • トークン 1 つ分ずれた位置を指すソースマップ

こうした報告は、作業の邪魔ではありません。データセットそのものです。

正しい対応は、それらをフィクスチャ、テスト、スナップショット、ベンチマークに変えることです。

「本番で使える」は、ラベルではなく振る舞い

「本番で使える」という状態は、README にそう書いたから実現するものではありません。

時間をかけて示される、次のような振る舞いのことです。

  • 不具合報告が、回帰テストになる
  • ベンチマークが、実際のワークフローを対象にしている
  • リリースノートが、リスクを説明している
  • 破壊的な変更が、意図したものである
  • CI が、サポートするプラットフォームを反映している
  • 診断が、自動化に使えるだけ安定している
  • ツールが何をするのかを、利用者が予測できる

Vize は多くの層に関わるため、これはとくに重要です。コンパイラの食い違い、リンターの偽陽性、型チェックの食い違い、誤ったソースマップは、それぞれ別の形で信頼を損ないます。

対象とする範囲が広いぶん、求められる水準も高くなります。

独立していることの利点

公式のツールには、別の種類の慎重さが求められます。

エコシステムからの期待を、すぐに背負うことになるからです。多くの利用者に影響を与えずに、大胆な実験をすることはできません。

Vize は独立しているので、素早く動く余地があります。

  • アーキテクチャの変更を試す
  • 内部を書き直す
  • 厳格な診断を追加する
  • 別のコンパイラバックエンドを試す
  • 弱い抽象化を取り除く
  • 性能のボトルネックを追いかける
  • すぐに安定させると約束せずに、コミュニティの報告から学ぶ

この速さは役に立ちますが、責任も伴います。

プロジェクトは、自分の現在地をはっきり示し、検証に真剣に取り組まなければなりません。

ロードマップは、フィードバックが形づくる

本番で使えるようになるまでの道のりは、機能のチェックリストだけではありません。

フィードバックのループです。

  1. 実際のプロジェクトで Vize を実行する。
  2. 失敗をすべて、テストかフィクスチャとして残す。
  3. 症状だけでなく、根本にあるモデルを直す。
  4. 公式のツールと動作を比較する。
  5. 性能を見える状態に保つ。
  6. 意外なケースが当たり前のケースになるまで、繰り返す。

ツールチェーンは、そうやって成熟していきます。

完成したふりをすることによってではありません。

実際のコード、実際の利用者、実際の制約に作業を形づくってもらい、信頼できるものになるまで続けることによってです。