はじめに
普段はVanilla JSでWebGIS開発しているんですが、ここ1年くらいでWebpack5に取り組んでどうにかこうにか使い慣れてきたところでした。
しかし、「もう少しビルド(バンドル処理)が早くできないものか、それになにげに設定事も難しいし」と情報収集をして、一瞬だけesbuildも試したけどすぐWebpack5に戻り、今に至ります。
風の便りに、「Vite」ってのがいいらしいと知ります。
「なぜ Vite なのか | Vite」には、様々なJS開発現場での問題点が指摘され、「特徴 | Vite」では良さそうな感じがします。 よし、ちょっとやってみようか、ちょうど別のプロジェクトが立ち上がるし、と。
【追記】昨今は、もうこのViteが手放せなくなりつつあります。Node.jsのバージョン管理はVoltaを使って、npmからviteを入れて簡単にバンドルしてます。
構築環境
- Windows 10 Pro
- WSL2＋Ubuntu-22.04を補助的に使っているけれど、ビルドなどはあくまでWindows上で完結させる
- IntelliJ PhpStorm（ビルドなどコマンドを実行するときはPhpStormの「ターミナル」から行っている）
- Vite v4.0系
- Node.js v18.16系、npm v9.8系とか
ここに紹介する設定で実現すること
- src/ と dist/ でディレクトリ管理できる。（webpack v5っぽく）
- 相対パス指定でバンドルされるので、サーバーのサブディレクトリ上に配置するのも簡単。
- 自作コードとnode_modules管理下のコードがチャンク別けできる。
- 開発版 development と本番版 production とでなるべく設定を共通ににして、違うところだけ定義を変更できる。
目指すディレクトリ構造
projectディレクトリトップ
│
├─src ディレクトリ（ビルド前のソース一式）
│ ├─index.html（コンテンツ入り口にあたるhtml）
│ ├─main.js（index.htmlから読み込まれる自作jsコード）
│ ├─style.scss（index.htmlから読み込まれる自作scssコード、バンドルによってcssに変換される）
│ │
│ ├─js ディレクトリ（自作モジュールjs置き場、main.jsでimportされる）
│ ├─css ディレクトリ（自作スタイルシート置き場style.scssでimportされる）
│ │
│ └─public ディレクトリ（配布物と一緒に置かれる静的コンテンツ類）
│ │
│ ├─img ディレクトリ
│ ├─json ディレクトリ
│ └─pdf ディレクトリ とか
│
├─dist ディレクトリ（ビルド後の配布物）
│ │
│ ├─assets ディレクトリ
│ │ │
│ │ ├─index.js（ビルド後のindex.htmlから読み込まれる）
│ │ ├─vender_a.js（node_modules由来のパッケージがひと塊）
│ │ ├─vender_b.js（node_modules由来のパッケージがひと塊）
│ │ └─index.css（ビルド後のindex.htmlから読み込まれる）
│ │
│ ├─public ディレクトリ（src/publicからコピーされる）
│ │
│ └─index.html（ビルド後のhtml）
│
├─node_modules ディレクトリ（パッケージ類の置き場所）
│
├─package.json
├─package-lock.json
└─vite.config.js（viteの設定ファイル）
vite.config.js の今
// vite.config.js
//import { splitVendorChunkPlugin } from 'vite' // 結局やめた
import { defineConfig } from 'vite'
export default defineConfig(({ command, mode, ssrBuild }) => {
// 設定オプション
var config = {
root: "src",
base: "./", // 相対パスでpublicなど参照できるように
publicDir: "public",
build: {
outDir: '../dist',
// emptyOutDir: true, // 絶対空にしないこと！
sourcemap: true,
rollupOptions: {
output: { // entry chunk assets それぞれの書き出し名の指定、ハッシュ値を使われると毎回変わって困るので
entryFileNames: `assets/[name].js`,
chunkFileNames: `assets/[name].js`,
assetFileNames: `assets/[name].[ext]`,
manualChunks: (id) => {
if (id.includes('node_modules')) {
if (id.includes('node_modules/ol/') || id.includes('node_modules/proj4/')) {
return 'vendor_ol';
} else if (
id.includes('node_modules/bootstrap/') ||
id.includes('node_modules/@popperjs/')
) {
return 'vendor_bs';
}
return 'vendor'; // all other package goes here
}
},
},
},
},
// plugins: [splitVendorChunkPlugin()],
}
if (mode === "development") {
return config;
}
else {
config.build.sourcemap = false; // ソースマップの出力抑止
return config;
}
})
いろいろ総合して、こうなった。
scssを使う上での設定や定義がいらないのが素敵。
古いブラウザ向けの互換性確保をするなら、「@vitejs/plugin-legacy」というプラグインを使えばいいらしいけれど、モダンブラウザだけ相手なので気にしない。
妥協点とか
publicDirについて
publicDirで指定したディレクトリは、ビルド時にdistディレクトリにコピーされるということだけど、たまたま今回Googleマップ互換のラスタータイル画像を大量に作ることになって、当初は publicDir で指定する public ディレクトリの下に全部置いていた。
そうしたら、数KB～十数KBの大量のファイルをディレクトリ構造ごとビルドのたびにコピーしているようで大変都合が悪かった。
ファイル数もファイルサイズもたかが知れているファイルであればいいけれど、さすがに時間が無駄なので、最近は dist にはじめから置いといて、その代わり dist から src にシンボリックリンクを張って開発サーバー（npm run dev）の動作に支障がないようにしている。
mklink /d にてWindows上でシンボリックリンクを作成
ちなみに、Windows 10/11でシンボリックリンクを張るためには、例えばコマンドプロンプトを管理者権限で起動した上で、srcディレクトリ上でmklink /d terrain ..\dist\terrainなどとしている。 エクスプローラ上でAltキーを押しながらドラッグすればショートカットが作れるのだけど、その場合実態は「terrain.lnk」などという拡張子がついてしまって具合が悪い。 なので、distにあるterrainを開発サーバーから参照できるようにするためには、srcディレクトリ上にてmklink /d リンク ターゲットとなるようにしておくと、npm run devにて開発サーバー実行中でも問題なく参照できるようになる。 WSL2ならln -sなんだろうけれど。
そのため、config.build.emptyOutDir は false にしておくべき、定義がなければ false になるのでコメントアウトしている。
チャンクの分割（これもお試し中→自動化をやめて手動で対応）
プラグインsplitVendorChunkPlugin()によって、venderのチャンクを分離できる。
これを使って dist/assets/vender.js として分離しても、パッケージ類がこってりとひと塊になっているので、500KBなんかはるかに超えちゃってる。
こういう場面でも、Dynamic Importとか活きてくるんだろうけど、まだ理解が追い付いていないので、追々。
手動でチャンク分割をやるようになった
500KBを越えないように分割せよってことなので、なんとなく近い機能まとまった機能ごとに分けようって発送になって、例えばBootstrap 5とそこで使ってる@popper.jsをひとまとめにしてみたり、OpenLayersと一緒に使ってるproj4jsをひとまとめにしてみたりして、括りだしていたりする。