
こんにちは。よっしーです(^^)
今日は、SvelteKitでの移行について解説しています。
背景
SvelteKitでの移行について調査する機会がありましたので、その時の内容を備忘として記事に残しました。
パスはデフォルトで相対パスになりました
SvelteKit 1では、app.html
の中の%sveltekit.assets%
は、paths.relative
設定オプションが明示的にfalse
に設定されていない限り、サーバーサイドレンダリング中にデフォルトで相対パス(つまり、レンダリングされるパスに応じて.
や..
や../..
など)に置き換えられていました。これは$app/paths
からインポートされたbase
とassets
でも同様でしたが、paths.relative
オプションが明示的にtrue
に設定されている場合のみでした。
このような一貫性のなさはバージョン2で修正されました。パスはpaths.relative
の値に応じて、常に相対パスか常に絶対パスのどちらかになります。より移植性の高いアプリになるため、デフォルトでtrue
に設定されています:base
がアプリの想定とは異なる場合(例えばInternet Archiveで閲覧される場合など)やビルド時に不明な場合(IPFSへのデプロイ時など)、問題が発生する可能性が低くなります。
解説
これはSvelteKitのバージョン1から2への変更点に関する説明です。主にパスの扱い方の変更について述べています。
- バージョン1での動作
app.html
内の%sveltekit.assets%
は基本的に相対パスに変換されました- ただし
paths.relative: false
と設定すると相対パスへの変換が無効になりました $app/paths
からインポートしたbase
とassets
は逆の動作でしたpaths.relative: true
と明示的に設定した場合のみ相対パスになりました- つまり、同じパスの扱いでも場所によって動作が異なっていました
- バージョン2での改善
- パスの扱い方が統一されました
paths.relative
の値によって、すべてのパスが:- 相対パス、もしくは
- 絶対パス
のどちらかに統一されます - デフォルトは
true
(相対パス)に設定されています
- 相対パスをデフォルトにした理由
- アプリケーションの移植性が向上します
- 以下のような状況でも正しく動作する可能性が高くなります:
- Internet Archiveでの閲覧時
- IPFSへのデプロイ時
- その他、想定と異なる環境での実行時
この変更により、開発者はパスの扱いについて混乱することが少なくなり、またアプリケーションの柔軟な展開が容易になったと言えます。
おわりに
今日は、 SvelteKitでの移行について解説しました。

何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント