こんにちはkubotakです。
弊社M&Aクラウドでは先日、Nuxt(v2系)のアプリケーションをSvelteKitへ移行を完了しました。
※一部ページは諸事情によりNuxtのままですが9割以上が移行済み。
本記事ではSveltekitへの移行した理由や移行方法について紹介したいと思います。
Vue2系がEOLを迎える
Vue.jsは現在3系となり、Vueをベースとして作られているWebフレームワークであるNuxtも現在3系が最新となります。
また、Vue.jsの2系は2023年12月31日*1に、Nuxtについても2系は2024年6月30日*2にサポート対象外になることが発表されています。
それに伴い弊社でもNuxtの2系の対応について検討がされました。
NuxtからSveltekitへ
まずはNuxt2から3への以降に際してどのようなマイグレーションが必要なのかを調査しました。
弊社のNuxt2はNuxt Typescript*3というプロジェクトをベースに作成したTypeScriptベースに、VuexやCompositionAPIを利用した構成になっており、2020年開発した当初ではモダンな構成を取っていました。
しかし、Vuexを多用しすぎたことやコンポーネントのroot（context）を多用したことでほぼ全てのコンポーネントに手を加える必要がありました。
そして、Nuxt2から3へ移行する際はBridgeというアップデートのための中間バージョンがありますが、そのバージョンに移行する時点ですでに多くの変更を要することがわかりました。
そのため、Bridgeを経由せずに別のリポジトリを用いて新たにNuxt3へ移行する手順が最善であると想定しました。
しかし、ほとんどのコードベースは引き継げない可能性が高い（Nuxt3によるモダンな書き方へ変更するなど考慮する場合）ため、別のフレームワークへ移行しても工数としてさほど差分がないという結論になりました
このことから弊社ではSveltekitへの移行を決断しました。
なぜSvelteKit？
弊社では過去にSvelteKitを採用したプロジェクトがあります。
これによりSvelteKitへの知見がすでにあることと、開発体験の良さから、Nuxt3ではなくSvelteKitへ全面的に移行することで弊社のフロントエンドの技術スタックをSvelteに絞ることにしました。
移行方法
Nuxt3移行への検討と同じ考え方として、新たにリポジトリを作成してアプリケーションを開発しました。
弊社ではNuxtとLaravelのアプリケーションがエンドポイント別で混在しており、本番環境ではCloudfrontのBehaviorでパスごとにリクエストを振り分けています。
ローカル開発においてはTreafikを利用してCloudfrontのBehavior相当にリクエストを振り分けて開発しています。
そこでChrome拡張のMod Headerを利用して特定のHeaderを設定した場合にTreafikのリクエストの振り分けが変わる仕組みを施しました。
これにより特定のHeaderがついている場合はSvelteKitのアプリケーションへ、そうでない場合はNuxt2の従来のアプリケーションを参照できるようにし、現在の仕様を動作確認しながら移行できる環境を作りました。
移行としてはほぼフルスクラッチでの作り直しとなります。
VueとSvelteはどちらも独自のテンプレートで作成しますが、ある程度のHTML構造は持ち越すことができました。
また、Storybookを活用しコンポーネント単位の移行とレビューを行い、VueのコンポーネントをSvelteに置き換えて行きました。
移行してどうだったか
移行期間としては3人のチームと外部委託の協力1人、最後の2週間ほどはさらに4人の協力を得て三ヶ月で移行が完了しました。
当初の見積もりとしても早くて3ヶ月と見積もったところほぼほぼその通りになりました（最終的には他チームの助力を得ましたが"早くて"という見積もりがしっくり来ます）
とにかく年内に移行しきる、という目標で遂行したので最後はだいぶゴリ押し感のある移行でしたが、無事完了できました。
こういったビジネス影響がない（開発者体験が大幅に向上したので、ビジネス影響が無いということはないが）プロジェクトの場合、長期間で実行するリソースがスタートアップ企業にはなかなかないと思います。
そのため、三ヶ月でやりきることができたのはとても良かったと思います。
ちなみにNuxt2のときにnpm run devを実行すると3分以上も立ち上がりに時間がかかっていましたがSvelteKitではViteで実行されるため数秒で起動が終わります。
移行してよかった〜
SvelteKitで開発した方はぜひぜひ弊社に入社ください。
