← ブログ一覧
📖 約10分

Vite 8.1、Astroのビルドは壊れないか検証

Vite 8.1のcaseSensitiveとadditionalAssetSourcesを実行検証。Astro ^6.3.7はネスト済みVite 7.3.6を使い続け恩恵が効かない実態をnpm lsで確認した。

ViteビルドツールAstro

この記事の結論: Vite 8.1のcaseSensitiveとhtml.additionalAssetSourcesは実際に動かして効果を確認できたが、jinbei-labが使うAstro ^6.3.7は自分専用にネストしたVite 7.3.6を持っているため、package.jsonでvite単体だけ8.1に上げても実際のビルドには何の影響も出ない。依存パッケージのバージョンを上げるときは、npm ls <パッケージ名>でネストされた別バージョンが残っていないか確認する習慣を持ち帰ってほしい。

リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、2026-06-23にリリースされたVite 8.1と、最新パッチ8.1.5をjinbei-labの手元環境で実際に動かして検証した回。（登場人物について）

タクヤ「リナ社長、Vite 8.1の最新パッチが8.1.5まで来てて、今朝サンドボックスで入れて動かしてみたんですけど、地味に実用的な修正が2つ入ってますよ。」

リナ「え、うちのブログってVite直接触ってたっけ？Astro経由でしか使ってなくない？」

タクヤ「そこ、まさに今回の検証で引っかかったポイントなんです。まず何が変わったかから見てもらっていいですか？」

Vite 8.1で何が変わったか

Vite 8.1は2026-06-23に公開されたマイナーバージョンで、最新パッチの8.1.5は2026-07-16付けで出ている（今日はJSTで2026-07-17）。細かい変更点は他にも含まれているはずだが、今回サンドボックスで実際に手を動かして確認できたのは次の2つに絞られる。それ以外の項目については、動かして確かめていない以上、この記事では扱わない。

  1. import.meta.globのcaseSensitiveオプション — グロブパターンの大文字小文字の扱いを明示的に指定できるようになった。
  2. html.additionalAssetSources — src以外の属性（例: data-src-darkのようなダークモード用画像パス）も、ビルド時アセットとして扱えるようになった。

どちらも「地味だが実務で刺さる」系の修正で、派手な新機能ではない。だからこそ、実際に動かして挙動を確かめる価値があると考え、以下の手順で検証した。

実際に動かして確認した点

まずVite単体をサンドボックスに導入した。

$ npm install vite@8.1.5 --save-dev
added 15 packages, and audited 16 packages in 4s

node_modules/vite/package.jsonのversionが"8.1.5"になっていることも確認済み。

caseSensitiveオプション

タクヤ「これ、地味に地雷なんですよ。大文字小文字を区別しないファイルシステム（Windowsとかmacosのデフォルト）で開発してて、Linuxのビルド環境で急にファイルが見つからなくなる、みたいな事故の元になってたので。」

検証用にsrc/Post.md（大文字P）を用意し、次のエントリを書いてSSRビルドした。

const exact = import.meta.glob('./src/Post.md', { query: '?raw', import: 'default' })
console.log('exact-case pattern (./src/Post.md):', JSON.stringify(Object.keys(exact)))

const wrongCaseDefault = import.meta.glob('./src/post.md', { query: '?raw', import: 'default' })
console.log('wrong-case, caseSensitive未指定:', JSON.stringify(Object.keys(wrongCaseDefault)))

const wrongCaseInsensitive = import.meta.glob('./src/post.md', { query: '?raw', import: 'default', caseSensitive: false })
console.log('wrong-case, caseSensitive:false:', JSON.stringify(Object.keys(wrongCaseInsensitive)))
$ npx vite build --ssr entry.js --outDir dist-ssr --emptyOutDir
✓ built in 29ms
$ node dist-ssr/entry.mjs
exact-case pattern (./src/Post.md): ["./src/Post.md"]
wrong-case, caseSensitive未指定: []
wrong-case, caseSensitive:false: ["./src/Post.md"]

大文字小文字が一致しないパターンは、caseSensitiveを指定しない状態（デフォルト）だとマッチせず、caseSensitive: falseを明示して初めてマッチした。Viteの型定義ファイルでもcaseSensitiveのデフォルトはtrueとされており、この実行結果と整合する。

html.additionalAssetSources

もう一つは、HTMLのimgタグにdata-src-darkのような独自属性でダークモード用の画像パスを持たせているケース。index.htmlに次のマークアップを用意した。

<img src="./src2/images/dark-logo.png" data-src-dark="./src2/images/dark-logo.png" />

設定なし（vite.config.jsなし）でビルドすると、次のようになった。

$ npx vite build --outDir dist
✓ built in 42ms
<img src="data:image/png;base64,ZHVtbXktcG5nLWJ5dGVzCg==" data-src-dark="./src2/images/dark-logo.png" />

srcはビルド時にdata URIへ変換されるが、data-src-darkはそのままの相対パス文字列で残っていた。これは本番環境ではファイルが存在しないパスになり、そのまま壊れる。

そこでvite.config.jsに次の設定を足して再ビルドした。

export default {
  html: {
    additionalAssetSources: {
      img: { srcAttributes: ['data-src-dark'] }
    }
  }
}
$ npx vite build --outDir dist
✓ built in 39ms
<img src="data:image/png;base64,ZHVtbXktcG5nLWJ5dGVzCg==" data-src-dark="data:image/png;base64,ZHVtbXktcG5nLWJ5dGVzCg==" />

設定を足すとdata-src-darkもsrcと同様にビルド時アセットとして解決され、data URIに変換された。ダークモード切り替え用の画像パスをHTML属性で持たせている構成だと、これは実際に効く修正だ。

タクヤ「この2つ、うちみたいに画像パスをちょこちょこ独自属性で持たせてるサイトには普通に嬉しい修正ですよ。地味だけど実害があった系のバグ潰しなので。」

リナ「ふーん、悪くなさそうじゃん。で、それウチらの何が変わるの？ブログの本番ビルド、今日から速くなったり安全になったりするわけ？」

Astroのビルドへの影響

ここでリナ社長の質問に答えるために、jinbei-labの実際の依存関係を確認した。

$ npm view astro@6.3.7 dependencies.vite
^7.3.2

jinbei-labのpackage.jsonに実際に記載されているastroのバージョンは^6.3.7で、そのastro自体が要求しているviteは^7.3.2だった。つまりVite 8系はそもそもastro@6.3.7の許容範囲に入っていない。

さらに最新のastroを見ると、要求するviteのバージョンが変わっていることも確認できた。

$ npm view astro dist-tags.latest
7.1.0
$ npm view astro@7.1.0 dependencies.vite
^8.0.13

ここで、「じゃあpackage.jsonのvite単体だけ8.1.5に上げておけば、とりあえずAstroのビルドにも部分的に恩恵があるのでは」という仮説を立て、別のスクラッチディレクトリでastro@6.3.7とvite@8.1.5を同時にインストールして検証した。

$ npm install astro@6.3.7 vite@8.1.5
added 262 packages, and audited 263 packages in 30s

$ npm ls vite
astro-vite-conflict@1.0.0
+-- astro@6.3.7
| +-- vite@7.3.6
| `-- vitefu@1.1.3
|   `-- vite@8.1.5 deduped
`-- vite@8.1.5

$ cat node_modules/astro/node_modules/vite/package.json | grep version
"version": "7.3.6",

結果ははっきりしていた。トップレベルのpackage.jsonにvite@8.1.5を追加しても、astro@6.3.7は自分専用にネストされたvite@7.3.6を持っており、Astroの実際のビルドはそのネストされたVite 7.3.6を使い続ける。エラーにはならないが、Vite 8.1の新機能（caseSensitiveやadditionalAssetSources）はAstro側のビルドには一切効かない。

タクヤ「これ、上げたつもりになって満足しちゃうやつですね……。node_modulesの中を見るまで気づけないパターンです。」

リナ「え、それめっちゃ無駄骨じゃん。うちのpackage.jsonでvite単体を8.1にバージョン固定しても、実際にビルドで動いてるのは相変わらず7.3.6ってこと？だったら今それやる意味なくない？」

タクヤ「そうなんです。恩恵を受けたいなら、Astro自体を7系（vite ^8.0.13を要求するバージョン）に上げないと意味がないですね。逆に言うと、Astroのメジャーアップグレードとセットで考えるべき話で、Vite単体を今すぐ急いで上げる理由は薄いと思います。」

リナ「うーん、あたし的には『新しいバージョンは基本入れとく』が安全側だと思ってたけど、今回はむしろ『入れても意味がないから触らない』が正解ってこと？技術的には地味に良い修正でも、ビジネス的にはROIゼロってことじゃん。それ、最初に言ってよ。」

タクヤ「機能自体は良い修正だと思ってるので評価は分かれるところですが、jinbei-labの現状に当てはめると、今Vite単体を上げる作業は工数に見合わないというのはリナ社長の言う通りですね。」

この二人のやり取りの通り、機能の質と「今それをやる価値があるか」は別の軸で評価する必要がある。Vite 8.1自体のcaseSensitiveやhtml.additionalAssetSourcesは、実際に手を動かして確かめた限り地味だが実害のあるバグを潰す良い修正だった。ただしjinbei-labのようにAstro ^6.3.7を使っている構成では、Astro自身がネストされたVite 7.3.6を握ったままなので、package.jsonのvite単体だけ上げても本番ビルドの挙動は何も変わらない。恩恵を受けるタイミングは、Astro自体を7系に上げるときになる。

まとめ・持ち帰り

今回の検証で確認できたのは次の3点だ。

  • Vite 8.1のcaseSensitiveとhtml.additionalAssetSourcesは、それぞれSSRビルドと通常ビルドで実際に動かして効果を確認できた。
  • jinbei-labが使うAstro ^6.3.7はvite ^7.3.2を要求しており、実際にnpmでインストールすると自分専用にネストされたvite@7.3.6を持つ。
  • そのため、トップレベルのpackage.jsonでvite単体を8.1.5に上げても、Astroの実ビルドが使うVite本体は変わらず、8.1の新機能は一切効かない。

読後に手元で試せる持ち帰りは1つ。Astro/Vite系のプロジェクトで依存パッケージのバージョンを上げるときは、まずnpm ls vite（対象がviteでなければnpm ls <パッケージ名>）を実行して、期待しているバージョンとは別のネストされたバージョンが残っていないかを確認してほしい。上げたつもりで実は何も変わっていない、という無駄骨を1コマンドで避けられる。

リナ「みんなのプロジェクトも、npm ls叩いたらネストされた別バージョンで生きてたりしない？意外とそういうの、誰も見てないと思うんだよね。」

参考

コメント