まえおき
開発を行うウェブ制作環境には幾つか種類がある。
- VueやReactなどのフレームワーク
- gulp.jsやGruntなどのタスクランナー
- webpackやViteなどのバンドラー
- Visual Studio CodeなどのIDE（統合開発環境）
- jQueryやBootstrapなどをCDNから読み込む
今回はViteを使った簡単な開発環境を用意してみた。
言語はPug・Sass (SCSS)・TypeScriptでの制作になっている。
前提環境は次の通り。
- Node.jsがグローバルインストールされていること
- VS Codeが使えること
- （可能であれば）Apacheなどでローカルサーバが動いていること
- GitHubアカウントがあり、GitHub Desktopがインストールされていて、それらの両方にログインしていること
ファイルとフォルダ作成
https://atpv5ro0rnli6in2ykhu0amqnb5qh88k.com/ が今回テスト用に作ったもの。
なんか知らんphewとかいう名前の、適当な出来のコーポレートサイト。
ドメイン名は適当に取得した（１円／１年契約）
タスクランナー・IDEなど、Viteは使わなくても以下の方法は可能。
GitHub Pages（やカスタムドメイン）を使った格安のウェブサイト制作はできるぞ。
プロジェクトフォルダを作る
フォルダ名をphewとして新規作成。
VS Codeを新しいウィンドウで開き、フォルダをドラッグ・アンド・ドロップ。
npm
npmの初期化。
npm init -yそのままViteを導入。
npm create vite@latest .インストール時の設問に対する回答は次の通り。
- Current directory is not empty. Please choose how to proceed:
- Ignore files and continue
- Select a framework
- Vanilla
- Select a variant
- TypeScript
npmパッケージを導入する。
npm i -D @macropygia/vite-plugin-pug-static sass globule @types/globule vite-plugin-minify fs dotenv bootstrap tailwindcss postcss autoprefixernpx tailwindcss init -pファイルの作成・編集
- サンプルファイル（削除または退避）
- index.html
- srcフォルダの中身を全部
- publicフォルダの中身を全部
- .gitignore（ファイル編集）
- （削除）dist行
- package.json（ファイル編集）
- （編集）scriptsを書き換え
- -local設定を伴ったbuild命令は、ローカルサーバで確認するためのフォルダパスに調整して出力する
- -githubpagesや-xserver設定を伴ったbuild命令は、それぞれのサーバ設定に応じて出力する
- URLやパスなどを変更する場合は.envに記述し、-githubpagesなどの識別子を変更する場合はvite.config.tsでの読み込み処理も書き換える
- tailwind.config.js（ファイル編集）
- （編集）contentを書き換え
- copyPublic.js（新規作成）
- .env（新規作成）
設定はフォルダやパスで、主にHTMLでのbase・meta・linkタグとaタグに使われる
- *_DEVは開発モード用なので変更不要
- *_LOCALはローカルサーバ用のため、各自の環境で適宜読み替え
- DOMAIN_*はドメイン名の末尾まで
- DOCROOT_*はドキュメントルートパスの開始から、プロジェクトフォルダの終わりまで
- SUBDIR_*はサーバ側でドキュメントルート直下をプロジェクトのルートディレクトリにしない場合に指定する
- PUBLIC_*はプロジェクトのルートディレクトリからpublicフォルダまでの相対パスを指定する
- *_GITHUBPAGESはGitHub Pagesとして公開する場合
- アカウント名とリポジトリ名は適宜読み替え
- *_XSERVERはレンタルサーバー（XServer）で公開する場合
ちなみに*_GITHUBPAGESでコメントアウトしている方はカスタムドメインでの設定（後述）
- vite.config.ts（新規作成）
- package.jsonで-xserverなどの識別子を変更した場合、26行目から51行目の処理も書き換えること
- 書き換える部分はcase文とdotenvの*_LOCALになっている部分のみ。後はcase ... breakブロックを増減させているだけなのでゴチャゴチャしているように見えてやることは地味
GitHubリポジトリの作成
プロジェクトフォルダをGitHub Desktopのウィンドウにドラッグ・アンド・ドロップしてリポジトリを新規作成する。
「create a repository」「Create repository」「Publish repository]」「Publish repository」と4回クリックすれば制作前の準備は全て完了。
フォルダ・パスの部分で少し面倒な部分はあるが、深く考えることはなく決まり事に沿って処理をするだけなので慣れだと思うがいい方法があれば改善の余地は大いにある。
おすすめの改善方法としては、.envの*_GITHUBPAGESと*_XSERVERの値だけを変更する以外は全部使い回すやり方。
制作
srcフォルダとpublicフォルダにファイルを作成・編集していくだけ。
開発モード中はViteのライブサーバーが稼働しているので、ブラウザのオートリロードで様子を見ながら制作できる。
フレームワーク・タスクランナー・バンドラーなどを使った制作と同じ感覚で行ける。
Git管理も（PrivateからPublicに切り替える以外は）自由。
開発モードはVS Codeのターミナルで操作。
- 開始
npm run dev- 終了
Ctrl + Cを2回入力確認用のURLはhttp://localhost:5173辺りになるがポート番号は変わる場合あり。
ターミナルにURLが出力されるので、それをCtrl + 左クリックするのが一番安全。
フォルダ構造とバンドル処理について
- src/*.pug
HTMLファイルとして、dist/*.html形式で出力される。
ファイル名が「_」で始まっている場合はファイル出力を行わないので、テンプレートやミックスインなどに使う。
- src/css/*.scss
CSSリソースデータとしてバンドラーが巻き取りdist/assetsフォルダに出力されるが詳細は後述。
ファイル名が「_」で始まっている場合は出力を行わない。
- src/ts/*.ts
Javascriptリソースデータとしてバンドラーが巻き取りdist/assetsフォルダに出力されるが詳細は後述。
ファイル名が「_」で始まっている場合は出力を行わない。
- src/img/*.(jpe?g|png|gif|svg)
画像系リソースデータとしてバンドラーが巻き取りdist/assetsフォルダに出力されるが詳細は後述。
Pugファイルの中で読み込み指定をしたものだけを選別してバンドルしてくれる。
- src/font/*.(woff2?|ttf|otf)
フォント系リソースとしてバンドラーが巻き取りdist/assetsフォルダに出力されるが詳細は後述。
Pugファイルの中で読み込み指定をしたものだけを選別してバンドルしてくれる。
- src/public/*
バンドル処理を回避して、静的なファイルとしてそのまま利用できる。
次の場合などに用いる。
- favicon.icoのように個別のファイルとして存在してほしい場合
- Pugの中には書かないためバンドル処理を外れてしまうがリソースデータとして使うことが確定している場合
Pug
基本的には通常のPug。
src/*.pug階層に置く。
基本的にはバンドラーであるViteでいい感じに処理してもらうため、srcフォルダ内部での相対パスを考えていればいいのはPug・Sass・TypeScript・画像などで共通。
- favicon.icoなど、publicフォルダを扱う場合
- meta[property="og:url"]など、モードによって絶対パスが変化する場合
- src/index.pug・src/company/index.pugなど、階層の異なるHTMLを出力する場合
全体的に注意するのは上記3点で、3つ目を除けばPugに受け渡すローカル変数が調整してくれる。
3つ目のようなサイト設計を行うと問題が複雑化する。
今回の制作環境は簡単なものなので、下記の仕組みを理解しないまま開発するのはおすすめしない。
- バンドラーに読み込ませたSassであるならば、CSSファイルを読み込む処理を書かなくてもいい
CDNから読み込むCSSは書く必要がある。
- バンドルされたsrc/(img|font)/**/*は、そのままの相対パスで書ける
img(src=img/footer.jpg", alt="")- headタグ内部のbase・meta・linkタグで指定するURLにはPugローカル変数を使う
開発モード・各種製品モードなどでURLが変わってくるものに対応するため。
例えばfavicon.icoとか。
link(rel="icon", href=innerPublicPath+"favicon.ico", sizes="any")上例のようにテンプレートを作ってしまったら、後は値を書き換えることなく使い回せるので深く考える必要はない。
- 階層化する時のaタグに注意する
全てがsrc/*.pugという風に同じフォルダで完結しているのなら問題は起きない。
a(href="page1.html") PAGE_1src/*.pug・src/post/*.pugのように、子階層を作る場合はPugローカル変数を使う。
a(href=rootAbsPath+"page1.html") PAGE_1ドキュメントルートが環境によって変わるので、その差異を吸収するための変数。
- アナリティクス関連のscript・iframeタグなどは、開発モードでは出力しないようにする
無駄にアナリティクス情報が送信されてしまうので。
- 個別のJavascriptファイルは読み込まない
bodyタグの閉じタグ手前に次の記述を行う。
script(type="module", src="ts/index.ts")ファイル名は自由。
このscript[type="module"]の中で、Javascript処理とSassの読み込みを行う。
ちなみに本来のViteの用途からは大きく外れている。
<body>
<div id="app"></div>
<script type="module" src="index.ts"></script>
</body>div#appのinnerHTMLをindex.tsによって書き換えるのが公式の方法。
今回の制作環境ではSSRなどを必要とせず、PugSassTSを使って楽にコーディングしたいのでこうなった。
Sass
基本的には通常のSCSS。
src/css/*.scss階層に置く。
- Tailwind CSSを使いたい場合、ファイルの先頭にディレクティブ設定を追記する
@tailwind base;
@tailwind components;
@tailwind utilities;Tailwind CSSを使わないのならディレクティブ設定も不要。
後述するBootstrapとも一応は共存できるが、クラス名が重複した時の挙動までは保証できないので@applyでの開発をおすすめ。
TypeScript
基本的には通常のTypeScript。
src/ts/*.ts階層に置く。
- CSS・Sassをインポートする
import '../css/index.scss'
import '../node_modules/bootstrap/dist/css/bootstrap.min.css'
import 'https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0/css/all.min.css'バンドルしたCSSやSass、npmパッケージとして取得したCSSやSass、CDNとして読み込みたいCSS（やJavascript）など、何でもインポートできる。
Sassが特殊な記述なしで読み込めるのは強い。
Bootstrapを読み込む設定として書いているが、要らないなら消していいし、Tailwind CSSと共存させた時のクラス名重複で何が起きるかは分からない。
- Javascript処理を書く
普通にJavascript処理も書く。
バンドルした画像・フォント等のリソース
src/img/*階層とsrc/font/*階層に置く。
- リソースの読み込みはPugファイルからの相対パスになる
src/index.pugからsrc/img/footer.jpgを読み込む場合こうなる。
img(src="img/footer.jpg" alt="")当たる前のように感じるが、ビルドを行うと相対パスの関係が変化する。
出力後のファイル名はdist/index.html・dist/assets/img/footer.jpgなので本来ならPugもそちらの階層差に従って「assets/img/footer.jpg」と書くべきところなのだが、その必要性はViteが解消してくれる。
assetsフォルダはViteがバンドルしたものをいい感じに処理する場所なので気にしなくてもいい。
バンドルしない画像・フォント等のリソース
public/*階層に置く。
- リソースの読み込みはPugローカル変数を使った絶対パスになる
public/favicon.icoなどはルート絶対パス（スラッシュで始まる形式）を使う。
link(rel="icon", href=innerPublicPath+"favicon.ico" sizes="any")public/og-image.jpgなどはスキーマ絶対パス（httpやfilesなどで始まる形式）を使う。
meta(property="og:image", content=outerPublicPath+"og-image.jpg")製品モードで書き出し
開発モードを終了して、製品モードでの出力を行う。
ローカルサーバ用に書き出して確認
npm run buildhttp://localhost/【distフォルダまでの相対パス】/dist/にアクセスして確認する。
レンタルサーバ用に書き出す
最後に自前で保有しているレンタルサーバにアップロードする。
下の2つをターミナルから実行して、出来上がったdistフォルダの中身をFTPソフトなどでアップロード＆動作確認して終了。
npm run build:xserver
npm run copynpm run copyは、publicフォルダをdist/publicフォルダとしてコピーするもの。
本来のViteは./index.htmlを使うため、同じ階層のpublicフォルダにもアクセスできるのだがsrcフォルダなども見えてしまうので余り良くない。
ドキュメントルートをdistフォルダに変更してdist/index.htmlを使うように設定したのだが、すると今度はpublicフォルダへとアクセスできなくなってしまった。
それを補うためのコピー処理となる。
【おまけ１】GitHub Pages用に書き出す
サーバ契約めんどくさい！
GitHub Pages使って無料でページ公開＆オートデプロイしたい！
な人向けのおまけ。
ビルド＆コピー
下の2つをターミナルから実行して、出来上がったdistフォルダの中身をFTPソフトなどでアップロード。
npm run build:githubpages
npm run copy公開リポジトリに変更
URLとしては「https://【GitHubアカウント名】.github.io/【リポジトリ名】」になる。
しかしこの時点ではウェブサイトとしての公開はPrivateリポジトリであるため行われない。
- github.comのリポジトリページへ移動
- Settings
- General
- Danger Zone（下の方にある）
- クリック「Change visibility」
- 選択「Change to public」
- クリック「I want to make this repository public」
- クリック「I have read and understand these effects」
- クリック「Make this repository public」
ルートディレクトリの変更して公開する
GitHubで管理しているフォルダの直下をルートディレクトリにしない場合。
今回はViteを使ってdistフォルダをルートディレクトリにしているので、適用先を変更するための設定を追加で行う。
- Settings
- Pages
- Build and deployment
- Source
- 選択状態を「Deploy from a branch」から「GitHub Actions」に変更する
- クリック「Static HTML」の「Configure」
- ファイル「.github/workflows/static.yml」がリポジトリ内に自動的に新規作成され、ファイルエディタが開かれるので編集する
jobs:
deploy:
# 中略
steps:
# 中略
- name: Upload artifact
# 中略
with:
# Upload entire repository
path: './dist/'jobs.deploy.steps["- name: Upload artifact"].with.pathの値が、初期状態では"."（あるいは"./"）になっている。
これを上例のように「"./dist/"」に変更する。
- クリック「Commit changes」
- GitHub Desctopでフェッチをして、ローカル環境にもstatic.ymlをプルしておくこと
これで公開処理が完了。
GitHub➡Settings➡Pagesの一番上にURLが表示されている。
「Visit site」をクリックして、ちゃんと表示されるかを確認して成功すればOK。
【おまけ１ａ】ルートディレクトリを変更する必要がない場合の公開処理
distフォルダとsrcフォルダを分けてリポジトリを作る構成にしておくと、dist側の公開処理をするだけで済む。
ルートディレクトリを変更する必要がないので、もっと簡単に手続きが完了できる。
- Settings
- Pages
- Build and deployment
- Branch
- 選択状態を「None」から「master」に変更する
- 選択状態が「/root」になっていることを確認する
- クリック「Save」
【おまけ２】独自ドメインで公開する
GitHub Pagesで公開する場合、URLは「https://【アカウント名】.github.io/【リポジトリ名】」という無味乾燥なものになってしまう。
法人名やイベント名など、好みの固有のURLに変更することも可能。
もちろん格安で。
一番最初に例示したドメイン名は１円（年間契約、次年度以降は別途）
レンタルサーバ代が発生しないのは魅力だがHTMLしか使えないのは弱点。
逆に言えば、そういう単純なサイト構成で短期掲載で充分ならば。
お名前.com
いくつか格安ドメインを取り扱う会社はあるが、試しに年間０円のお名前.comで契約してみた。
結論から言うと、不採用。
設定が悪いのかシステム的な問題なのか、サイトにログインした直後はドメインとして機能してくれるが、ログアウトしてしばらくするとアクセスしても繋がらなくなる。
CNAME設定が拙かったのかも知れないが、次の方法で成功してしまった後の祭りで気付いたので時すでに遅し。
設定方法はこちらを参考にした。
「DNS設定」➡「DNSレコードを利用する」の順にメニューを選択。
- ホスト名「www」、TYPE「CNAME」、VALUE「【GitHubアカウント名】.github.io」
- ホスト名「(空欄)」、TYPE「A」、VALUE「185.199.108.153」
- ホスト名「(空欄)」、TYPE「A」、VALUE「185.199.109.153」
- ホスト名「(空欄)」、TYPE「A」、VALUE「185.199.110.153」
- ホスト名「(空欄)」、TYPE「A」、VALUE「185.199.111.153」
XServer Domain
次に試したXServer Domainはうまくいった。
元々このブログもXServerで契約していたし、０円か１円かの違いでしかなかった。
ちなみにXServerのレンタルサーバー側でサブドメインを切ってみたが、これはうまく行かなかった。
設定方法はこちらを参考にした。
ネームサーバー設定
- ドメイン適用先サービス「XServer Domain」
DNSレコード設定
- ホスト名「(空欄)」、種別「A」、内容「185.199.108.153」
- ホスト名「(空欄)」、種別「A」、内容「185.199.109.153」
- ホスト名「(空欄)」、種別「A」、内容「185.199.110.153」
- ホスト名「(空欄)」、種別「A」、内容「185.199.111.153」
- ホスト名「(空欄)」、種別「AAAA」、内容「2606:50c0:8000::153」
- ホスト名「(空欄)」、種別「AAAA」、内容「2606:50c0:8001::153」
- ホスト名「(空欄)」、種別「AAAA」、内容「2606:50c0:8002::153」
- ホスト名「(空欄)」、種別「AAAA」、内容「2606:50c0:8003::153」
GitHub
ドメイン契約が完了したら、GitHub Pagesとの連携設定を行う。
Settings➡Pages➡Custom domain
- チェックを付ける「Enforce HTTPS」
- 入力欄にドメイン名をコピー＆ペーストして「Save」をクリックする
ドメイン名なので、URLのような「http」で始まる形式ではなく「hoge.fuga.com」などとする必要がある。
お名前.com側の設定ではCNAMEを指定したので、指定ドメインの先頭に「www.」が必要。
逆にXServer DomainにはCNAME設定を付けなかったので「www.」は不要。
DNSフェッチに時間が掛かるのでしばらく待機。
最長で24時間とは言われるが、短ければ数分で終わる。
体感、平均で10分以下。
ページリロードをすれば、ページ最上部の「Visit site」ボタン横で表示されているURLが指定したドメインに変わっている。
ページ表示をしてみて動作確認。
DNSキャッシュが切れるまで待って再アクセスしても間違いなくページ表示ができるようなら完了。