Svelte入門：SvelteKitでのパッケージング -Vol.4-

今日は、SvelteKitでのパッケージングについて解説しています。

背景

SvelteKitでのパッケージングについて調査する機会がありましたので、その時の内容を備忘として記事に残しました。

ベストプラクティス

SvelteKit特有のモジュール使用に関する注意

パッケージが他のSvelteKitプロジェクトでのみ使用されることを意図している場合を除き、$app/environmentのようなSvelteKit特有のモジュールの使用は避けるべきです。

例：

• 非推奨：import { browser } from '$app/environment'
• 推奨：import { BROWSER } from 'esm-env'

また、$app/storesや$app/navigationなどに直接依存するのではなく、現在のURLやナビゲーションアクションをプロップとして渡すことを検討してください。このような汎用的な方法で実装することで、テストやUIデモなどのツール設定も容易になります。

エイリアスの設定

エイリアスはsvelte-packageで処理されるように、vite.config.jsやtsconfig.jsonではなく、svelte.config.jsで追加するようにしてください。

バージョン管理の重要性

パッケージの変更が以下のどれに該当するか慎重に検討し、それに応じてパッケージバージョンを更新してください：

• バグ修正
• 新機能追加
• 破壊的変更

特に、既存ライブラリのexportsからパスを削除したり、その中のexport条件を変更したりする場合は、破壊的変更として扱う必要があります。

package.jsonの例と破壊的変更の具体例

{
    "exports": {
        ".": {
            "types": "./dist/index.d.ts",
            // `svelte`を`default`に変更するのは破壊的変更:
            "svelte": "./dist/index.js",
            "default": "./dist/index.js"
        },
        // これを削除するのは破壊的変更:
        "./foo": {
            "types": "./dist/foo.d.ts",
            "svelte": "./dist/foo.js",
            "default": "./dist/foo.js"
        },
        // これを追加するのは問題ない:
        "./bar": {
            "types": "./dist/bar.d.ts",
            "svelte": "./dist/bar.js",
            "default": "./dist/bar.js"
        }
    }
}

重要なポイント

1. モジュール依存性

• SvelteKit特有のモジュールへの依存は最小限に
• より汎用的なアプローチを採用
• 依存関係はプロップを通じて注入することを推奨

1. 設定管理

• エイリアス設定はsvelte.config.jsに集中
• 他の設定ファイルでの重複を避ける

1. バージョニング規則

• exportsからのパス削除は破壊的変更
• 条件の変更（例：svelte→default）は破壊的変更
• 新しいパスの追加は非破壊的変更

このベストプラクティスに従うことで、より保守性が高く、他のプロジェクトとの互換性のあるパッケージを作成することができます。

おわりに

今日は、 SvelteKitでのパッケージングについて解説しました。