この記事は、Angular Advent Calendar 2017の記事でした。公開日に間に合わず、枠をキャンセルしましたので一般記事として公開します（関係者の皆さん大変ご迷惑おかけしました）

とても魅力的なAngular/Ionicのバージョニングが残念な論調で語られるのを聞いたので、プロダクト採用という視点で改めてバージョニングについて見直したいと思います。

Angular/Ionicのバージョニング

Angular/IonicはSemantic Versioning(SemVer)を採用しており、Angularは今後のバージョンアップは6ヶ月毎のサイクルでメジャーバージョンを更新することを宣言しています。Ionicが利用している ionic-angular もAngularに依存しているので、Angularほど厳格ではないものの、ほぼそれに伴ったメジャーバージョンの更新を行っています。

時期	バージョン
2017/09	Angular 5
2018/03	Angular 6
2018/09	Angular 7
2019/03	Angular 8

まぁ、Angular 5がリリースされたのが11月（2ヶ月遅れ）なので、そこまで厳密なものではありませんが。一応は、最新版に追随しつづけようとすると、6ヶ月に1回は新APIがきて、1年毎に破壊的変更がくる可能性が高いわけです。

バージョニングの背景

AngularJSの反省によるものです。後方互換を気にしすぎたために、フロントエンドの最新技術を取り込むことができずに、リリース当時先進的だったAngularJSは、Components指向の開発、npmによる共通リソースを活用などの時代の変化をキャッチアップできず、徐々に時代遅れになっていきました。

Angular 2が発表された時に、「これはAngularシリーズなのか？！」「全く別物だ」「アップグレード無理じゃない？」「ng-upgradeつらみしかなさそう」とざわめいたのはまだ記憶に新しいのではないでしょうか。

そこで、Angularチームは「安定性が重要」といいながらも、新たに生まれる技術をキャッチアップするために「予測できる形で新技術を導入しつづける」ために、このバージョニングを採用しました。

参考： http://angularjs.blogspot.jp/2016/10/versioning-and-releasing-angular.html

これまでのバージョニングの恩恵

実際にこのバージョニングの変更によって、現在私は以下のような恩恵を受けています。すべては書ききれないので、思いついたものだけご紹介します。

TypeScriptのバージョンアップ

dependencyにあるTypeScriptのバージョンが1から2にアップデート。このことにより、サポートされている文法が増えました。

TypeScript 2 のモダンな書き方
https://qiita.com/karak/items/ef69aa71c19932fa5c1b

コンパイルのサイズ縮小

ビルドサイズが最大60%削減されました（公式発表）。実際にウェブサイトの表示が高速化された実感はあります。

参考
http://angularjs.blogspot.jp/2017/03/angular-400-now-available.html

Angular2 AoTコンパイルでTechFeedを高速化した話
https://medium.com/@techfeed/angular2-aot%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB%E3%81%A7techfeed%E3%82%92%E9%AB%98%E9%80%9F%E5%8C%96%E3%81%97%E3%81%9F%E8%A9%B1-55efa68189a5

Lazy Loading

Lazy Loadingが実装されました。これにより、JSファイルを分割して、必要なものだけを先にダウンロードしてもらうことが可能になりました。コンパイルサイズの縮小とあわせて、アプリの規模によっては数秒単位での高速化が実現します。

HttpClientModule

Angular 2ではHttpModuleがデフォルトだったのですが、Angular 4.3でHttpClientModuleが追加されました。まだAngular 2がでたばかりではAPI活用はjson以外も散見されたのですが、最近ではjsonがほとんどなのでjsonデフォルトに変更されています。
また、型付けがやりやすくなっており、ミドルウェア的にHttp通信をハックできる Interceptor という機能も新設されています。

HttpModuleからHttpClientModuleに乗り換えたら、実装がとても快適になりました。

プロダクト視点からのAngular/Ionicのバージョニングの魅力

「安心感」の一言につきます。プロダクトのテクニカルな寿命は、依存するフレームワークと開発者の最新技術のキャッチアップに依存する部分が大きいと思っています。ですので、AngularJSを採用しているプロダクトはキャッチアップすることができず、改善しようと思うと「フレームワークを乗り換えて、すべて書き直す」必要さえありました。

一方、Angular/Ionicは最新バージョンの追随さえすれば、一定のキャッチアップは保証されています。それは破壊的APIがくること以上に大きなメリットであり、プロダクト寿命を延ばすことにつながります。

そういう意味だと、短期的なアプリーー受託して納品して終えるような手をいれつづけないものにはこのバージョニングはメリットはないかと思います。逆に「開発中にバージョンあがった！！」というのは混乱を起こすこともありえて、敬遠する開発者がいることもわかります。おそらくこういったシチュエーションを指して「変更が激しい」みたいな話になるのだと思います。

しかし、長期運用前提の場合だとそれは当てはまりません。実際にIonicを採用した私が開発してるアプリは、手をいれる時間がなくバージョンをあげているだけのものも、ユーザには「改善されていってる」と評価をいただいています。ルーティングから、Http通信まわり、コンパイルまでが総合的に最新技術をキャッチアップしてバージョンアップされている恩恵は、長期運用するアプリにとってはとてもメリットが大きいことを実感しています。

おわりに

ぜひ本稿が、「フレームワークの破壊的変更は悪」という思い込みをすてる一助になりましたら幸いです。

それでは、また。