SvelteKitアプリケーションをGitHub Pagesにデプロイする
プライベートでアプリを書くことがめっきり減っちゃったなー、との昨年の反省から、2023年始はv1.0がリリースされたてのSvelteKitで遊んでいました。
SvelteKit上での開発は簡単な検証程度で済ましながら、SSGとして静的リソースを吐き出した上でGitHub Pagesにデプロイするまで、との一貫したフローを一通り踏んだため、今回は特に開発完了後の
- 静的リソースを作る様に設定をして
- GitHub Pagesにデプロイする
の部分の手順をメモとして書き落とします。
SvelteKit
adapter-static を設定する
SvelteKitはビルドを行った後、adapter と呼ばれる機構でデプロイ用のリソースを生成する様です。GitHub Pagesは index.html をエントリーポイントにした静的リソースを求めているため、adapter 周りも静的リソースを作る様に定義を書いていきます。
まず、svelte.config.js でデフォルトで定義されている adapter を adapter-static に修正。
$ npm i -D @sveltejs/adapter-static
- import adapter from '@sveltejs/adapter-auto';
+ import adapter from '@sveltejs/adapter-static';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter()
}
};
export default config;
src/routes の +layout.js でプリレンダリング対象であることを設定する
adapter-static のドキュメントに沿い、最上位の +layouts.js にてプリレンダリングを有効化する様に設定をします。
+ export const prerender = true;
基本的に、SvelteKitでの静的リソース生成はこれで完了です。めちゃくちゃ簡単！
$ npm run build
を実行すると、build 配下にリソースが配置されますが、その中には index.html 等の静的リソースがきちんと配置されていると思います。
GitHub Pages向け／ベースパスを設定する
ただし、GitHub Pagesにデプロイする場合は
# local
- https://localhost:XXXX
# GitHub Pages
+ https://{ユーザー名}.github.io/{リポジトリ名}
と、ルートパスとしてホスト名にプラスで {リポジトリ名} が必要になるため、若干設定を足す必要があります。
import adapter from '@sveltejs/adapter-static';
+ const dev = process.argv.include('dev');
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter(),
+ paths: {
+ base: dev ? '' : '/{リポジトリ名}'
+ }
}
};
export default config;
上記は adapter-static のサンプルのままですが、本番の場合はベースパスに {リポジトリ名} を設定する様にしています。ちゃんとしたアプリケーションならば NODE_ENV で判別する形で書くと思いますが、やることとしては上記と大差無い理解です。
paths.base を設定すると、アプリ上で書く相対パス周りも下記の様に $app/paths から呼び出す形で書くことが出来ます。
<script>
+ import { base } from '$app/paths';
</script>
- <a href="/posts/a"></a>
+ <a href="{base}/posts/a"></a>
npm run build を再度走らせて、リンク箇所のパスに base で指定した設定が入っていれば成功です！
GitHub
アクセストークンを準備する
今回はGitHub ActionsからGitHub Pagesにデプロイをかけるべく、ページ用のブランチを生成するため、リポジトリ操作用にアクセストークンを取得しておきます。
アクセストークンは「Settings -> Developer settings -> Personal access tokens」で生成出来ます。権限範囲は repo にチェックが入っていれば問題無し。
生成が完了するとアクセストークンが一度限り表示されるため、エディタ等に控えておきましょう。
アクセストークンをSecretsに設定する
アクセストークンの様な機密情報を利用する場合は、GitHub側で提供をしているキーストアであるSecretsの仕組みを利用します。
「Settings -> Secrets -> Actions」に行くと、「New repository secret」とのボタンがあるため、こちらからキー／バリューの形式でアクセストークンを設定します。今回は GH_API_TOKEN として登録をしたとします。
GitHub Actionsを組む
設定例を配置しておきます。
name: deploy-to-github-pages
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: setup node.js
uses: actions/setup-node@v3.6.0
# package.jsonの内容でパッケージインストール
- name: setup app env
run: npm i
# ビルド実行、静的リソースを作る
- name: build static resources
run: npm run build
# GitHub Pagesにデプロイする
- name: deploy to github pages
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GH_API_TOKEN }}
# アプリ直下のbuildディレクトリに生成されるため、指定
publish_dir: build
めちゃくちゃ簡単！
まとめ
ばっさりと省いた開発箇所も含めてですが、簡単・簡素なフレームワークで最高です。Svelte本体が容量・コード記述量の両面から簡素さを重んじたライブラリ（正しくはコンパイラなのですが）でしたが、SvelteKitもそのポリシーをしっかりと大事にした仕上がりで、面倒な箇所がほとんど無かったです。こういうのでいいんだよ、こういうので。
NuxtもNextも、個人的にはデファクトスタンダードになる過程で、フレームワークとしてカバーする範囲が広がった結果、各所でやりたいことのシンプルさに比べると作りが面倒になっちゃうなー、との場面にいくらか遭遇する様になった感覚があります（Nuxt3は環境変数周りでめちゃくちゃハマった、、）。SvelteKitは根本のポリシーである簡素さを重んじたまま、この調子でさらなる洗練を楽しみにしたいと思います。
Discussion