こんにちは。よっしーです(^^)
今日は、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での移行について解説しました。
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント