💡

【SvelteKit 入門】作業の前に

2022/10/08に公開

この記事はやや初歩の内容が多いですが、読むのに時間はかかりません。「先に言えよ」と後でつぶやく事態を回避できる可能性が少しあるので、目を通してみてください。


シリーズまとめ(随時追加・更新)

【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は現行バージョン(18.x)以降であれば気にする必要ありません

環境構築不要の選択肢「ブラウザエディタ」

SvelteKit は StackBlitz 上で試すことができます。

  • ローカルに環境を作りたくない方
  • 本腰入れる前に、一旦どんなものか試したいだけ

という方は、検討してみてください。
リンクから飛ぶと、公式のデモアプリで初期化されたプロジェクトがブラウザ内で起動します。

https://sveltekit.new/
↑ 公式に記載があるStackBlitzへの直リンク。
「sveltekit.new」というドメインでリダイレクトしており、恒常的なリンクかは不明。

プロジェクト作成時の私流アレンジ

プロジェクトの立ち上げは公式のトップページに従えば問題ありません。
しかしここでは私のアレンジを紹介しますので、参考にしてみてください。

実はコマンドの1行目

npm create svelte@latest my-app

ここの my-app は好きに変更する部分ですが、丸ごと省略すると 子ディレクトリは作成されずカレントディレクトリに構築されます。

$ npm create svelte@latest
    ↓
  Where should we create your project?
  ❚ (hit Enter to use current directory)

「プロジェクト作るの、ここで良い?」と確認されるので軽快に空エンター

これを踏まえ、私がSvelteKitのプロジェクトを立ち上げる際の作業は以下のようになります。

  1. 空のディレクトリを作る
  2. その場所でエディタを立ち上げる
  3. エディタのターミナルで ↑ のコマンドを打つ

私の場合、検証中の技術はプロジェクトのリセットマラソンをよくやるんですが、このやり方で
「ディレクトリの中身全削除 → 初期化コマンド」
とすれば、エディタを開いたままディレクトリに入りっぱなしでリスタートできます。

実行に関するコマンド整理

初期状態では以下の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
アダプター設定後

【補足】ビルドのコマンドっていつ使うの?

ローカルマシンでビルドしてそのファイルを… というケースが減ってるのは事実です。
よくデプロイ先として利用されるホスティングサービスの場合

  1. GitHub からソース部分のみ取得
  2. そのサービス内で ビルド & 配置(デプロイ)

ここまでやってくれるので、手元でビルドする必要がありません。他の手段でデプロイする場合も、極力そのデプロイ先でビルドするようにCI/CDを構築します。そのため npm run build は自分で打つコマンドというより、設定項目として入力するケースが多いです。

ただ、デプロイ時にエラーが出た場合は
ローカルで npm run buildnpm run preview でエラーの有無を確認
のような手順でエラー発生場所の切り分けに使うことはあります。

【補足】node build みたいなコマンド見たけど・・・

Node 環境ではnode jsファイルパスというコマンドで JavaScript コードを実行します。
JavaScript は複数ファイル群で1つのアプリケーションを構成します(単体ファイルの場合もある)が、最初に実行するファイルは1つです。それが普通はindex.jsであり、エントリポイントと呼ばれます。

つまり Node.js のアプリケーションというのは

  1. 完成したらビルドを実行
  2. buildpublicといったディレクトリにファイル群が出力される
  3. その中にindex.jsがある
  4. それをnode build/index.jsnode pablic/index.jsで実行

こういう流れです。そしてファイルではなくディレクトリを指定した場合は自動でindex.jsを探すので、出力先をbuildにした場合はnode buildが実行コマンドとなります。

node buildnpm run build はほぼ同時に記載される事が多いので、Node.js に馴染みのない方にとってはコマンドの一部・コマンドのオプションのように見えるかもしれませんが、node buildbuildはディレクトリのパスです。

Discussion