まとめ

• ビルとの実行コマンド、設定をライブラリとして切り出す
• ビルドツール系はモノレポ化してメジャーバージョン単位で管理し、後方互換性を残す
• アプリケーション側にビルドの拡張をなるべくさせない
• 拡張が必要なものはおそらく事前にビルド可能

原因

• デプロイするファイル構成の規格が存在しない
• ビルド設定が複数のリポジトリで管理されている

対策

Frameworkが提供するプレーンな状態のビルド設定をそのまま利用している内は、メンテナンスをFramework側に任せることができるため管理可能な状態にある。 しかしながら、特定のライブラリやファイルをバンドルしようとした際に非対称な設定が一度持ち込まれるとメンテナーを付ける必要がある。 ビルドツールの特徴として、一度導入すると長い間使われ、次にメンテナンスするまでの期間が空くことにある。 結果としてなぜこれが必要だったのかという情報が失われ、設定の共通化を試みようものなら失われた背景から探索する必要がある。

裏を返せばこの特徴はライブラリ向きとも言える。ライブラリとして管理することでCHANGELOGにビルドの変更内容を書いたり、 セマンティックバージョンとして運用することで利用者に破壊的変更や機能追加を伝えることができる。 また、アプリケーションがスケールするような場合、ビルド設定のポータビリティがあるためにすぐにビルドを適用することができる。

対策の動機

メンテナーはスケールしないので、メンテナンスする対象を一元化する。

導入方法

lernaを用いたモノレポで管理する。たとえば、webpack 3、webpack 4などメジャーバージョン単位でパッケージを分離する。

継続方法（運用）

ビルド設定のコアメンテナーを書く。

対策の問題点

ビルド設定の知識が必要。

展望

アプリケーション側で利用するビルドコンフィグがゼロとなること

参考資料