この記事はやや初歩の内容が多いですが、読むのに時間はかかりません。「先に言えよ」と後でつぶやく事態を回避できる 可能性が少しあるので、目を通してみてください。
シリーズまとめ(随時追加・更新)
【SvelteKit 入門】はじめに | |
【SvelteKit 入門】作業の前に | now reading |
【SvelteKit 入門】アダプター設定・ホスティング・コンテナ運用 | |
【SvelteKit 入門】ルーティング | |
【SvelteKit 入門】データハンドリング(+page.js) | |
SvelteKit + microCMS でブログ構築 |
環境確認
公式では当たり前のようにスルーしていますが、Node(npm)環境で開発します。
環境構築は解説しませんので、確認コマンドのみ載せておきます。
# Node.js 確認
node --version
node -v
# npm 確認
npm --version
npm -version
npm -v
npm version
※ Nodeバージョンは16.14
以上が必要
環境構築不要の選択肢「ブラウザエディタ」
SvelteKit は StackBlitz 上で試すことができます。
- ローカルに環境を作りたくない方
- 本腰入れる前に、一旦どんなものか試したいだけ
という方は、検討してみてください。
リンクから飛ぶと、公式のデモアプリで初期化されたプロジェクトがブラウザ内で起動します。
最新ver.のデモアプリは「SVERDLE」というミニゲームなんですが、おそらく通信まわりの問題で StackBlitz上だとエラーが出ます。ルーティング等の機能は試せます。
https://node.new/sveltekit
↑ 公式に記載があるStackBlitzへの直リンク。
「node.new」というドメインでリダイレクトしており、恒常的なリンクかは不明。
プロジェクト作成時の私流アレンジ
プロジェクトの立ち上げは公式のトップページに従えば問題ありません。
しかしここでは私のアレンジを紹介しますので、参考にしてみてください。
実はコマンドの1行目
npm create svelte@latest my-app
ここの my-app
は好きに変更する部分ですが、丸ごと省略すると 子ディレクトリは作成されずカレントディレクトリに構築されます。
npm create svelte@latest
↓
? Where should we create your project?
(leave blank to use current directory) > ❚
「プロジェクト作るの、ここで良い?」と確認されるので軽快に空エンター
これを踏まえ、私がSvelteKitのプロジェクトを立ち上げる際の作業は以下のようになります。
- 空のディレクトリを作る
- その場所でエディタを立ち上げる
- エディタのターミナルで ↑ のコマンドを打つ
私の場合、検証中の技術はプロジェクトのリセットマラソンをよくやるんですが、このやり方なら
「ディレクトリの中身全削除 → 初期化コマンド」
とすれば、エディタを開いたままディレクトリに入りっぱなしでリスタートできます。
実行に関するコマンド整理
初期状態では以下の3つのコマンドがあります
npm run dev | 開発用 |
npm run build | リリース版のビルド |
npm run preview | ↑ のプレビュー |
Ctrl + c | 停止 |
以下簡単に解説。
npm run dev 開発用
編集内容が即時反映されるホットリロード状態。開発に便利な機能を色々付帯しての起動。
SvelteKit に限らず、入門記事ではこういった開発用コマンドまで紹介され「ほーらもう立ち上がったでしょ?あとは頑張れ!」と放り出される。
初心者から「本番もこれで起動すればよくね?」という声を稀に聞きます。しかしパフォーマンスは本来のものではないので、本番ではきちんとビルドしたものを立ち上げてください。
npm run build ビルド
変換が必要なものは全て処理したファイル群を出力。本来のパフォーマンスで動作する。
デフォルト設定のままだと.svelte-kit
の中にしれっと出力されるだけなので、次のコマンド(npm run preview)専用状態。適切な設定の後に実行することで、様々なデプロイ先に対応した形で出力可能。
npm run preview ビルドチェック用
ソースコードではなく、npm run build
で出力されたファイルでの起動。直近のビルドまでの変更しか反映されないので注意。当然まだ1回もビルドを実行していないとエラーになる。
デプロイ先での起動をローカルで再現するイメージ。
起動する段階を表にするとこうなる
npm run dev | npm run preview | ホスティング先で稼働 | |
---|---|---|---|
npm install 直後 |
○ | ✕ | ✕ |
npm run build 後 |
○ | ○ | ✕ |
アダプター設定後 | ○ | ○ | ○ |
【補足】ビルドのコマンドっていつ使うの?
ローカルマシンでビルドしてそのファイルを… というケースが減ってるのは事実です。
よくデプロイ先として利用されるホスティングサービスの場合
- GitHub からソース部分のみ取得
- そのサービス内で ビルド & 配置(デプロイ)
ここまでやってくれるので、手元でビルドする必要がありません。他の手段でデプロイする場合も、極力そのデプロイ先でビルドするようにCI/CDを構築します。そのため npm run build
は自分で打つコマンドというより、設定項目として入力するケースが多いです。
ただ、デプロイ時にエラーが出た場合は
ローカルで npm run build
→ npm run preview
でエラーの有無を確認
のような手順でエラー発生場所の切り分けに使うことはあります。
【補足】node build
みたいなコマンド見たけど・・・
Node 環境ではnode jsファイルパス
というコマンドで JavaScript コードを実行します。
JavaScript は複数ファイル群で1つのアプリケーションを構成します(単体ファイルの場合もある)が、最初に実行するファイルは1つです。それが普通はindex.js
であり、エントリポイントと呼ばれます。
つまり Node.js のアプリケーションというのは
- 完成したらビルドを実行
-
build
やpublic
といったディレクトリにファイル群が出力される - その中に
index.js
がある - それを
node build/index.js
やnode pablic/index.js
で実行
こういう流れです。そしてファイルではなくディレクトリを指定した場合は自動でindex.js
を探すので、出力先をbuild
にした場合はnode build
が実行コマンドとなります。
node build
と npm run build
はほぼ同時に記載される事が多いので、Node.js に馴染みのない方にとってはコマンドの一部・コマンドのオプションのように見えるかもしれませんが、node build
のbuild
はディレクトリのパスです。