2026年現在の私のAstro開発環境

公開タグ:

3年前、「Web制作用のAstroテンプレートを公開しました」という記事を書きました。

このテンプレートは現在も定期的にメンテナンスしており、Astroのバージョンアップに合わせて変更したり適宜新しいツールを導入したりして、自分なりの最新のAstro開発環境になるようにしています。

この記事では上記のテンプレートを改めて紹介しつつ、なぜ今この構成なのかを書いていきます。

リポジトリ

テンプレートのリポジトリはこちらです。（新しいタブで開く）

テンプレートの機能

このテンプレートには以下の機能があります。

  • フレームワークとしてAstroを使用
  • TypeScriptによる型チェック
  • Destyle.cssによるスタイルのリセット
  • コードの自動リント・フォーマット
  • コミット前のファイルのリント、フォーマット、エラーの検知
  • GitHub ActionsによるCI
  • Renovateによる依存パッケージの更新

セットアップと使い方

まずは依存パッケージをインストールし、Gitフックをセットアップします。

# Install dependencies
npm i

# Set up Git hooks
npx lefthook install

次に、astro.config.mjsのsiteを自分のサイトのURLに書き換えます。siteはサイトの絶対URLを指定する項目で、サイトマップの生成などに使われます。

export default defineConfig({
  site: "https://www.my-site.dev", // set your site URL.
  // ...
});

あとはpackage.jsonに定義した以下のコマンドで開発を進めます。

# 開発サーバーを起動（localhost:4321）
npm start

# 本番ビルド
npm run build

# 本番ビルドのプレビュー
npm run preview

# リント
npm run lint

# リント・フォーマットの自動修正
npm run fix

# 型チェック
npm run check

テンプレートの技術的背景

Astro

AstroはコンテンツメインのWebサイトの制作に強いフレームワークです。

3年前に記事を書いた時点でもすでに注目度の高いフレームワークでしたが、現在もその勢いは衰えていません。

State of JS 2025（新しいタブで開く） では利用者のうち肯定・否定を表明した人の満足度は94%（新しいタブで開く）と、高く評価されています。

私個人としてもAstroには非常に満足しています。今でもWebサイト制作における選択肢の筆頭です。

日本国内でも徐々に採用される事例は増えてきているようで、ギャラリーサイトでAstro製のサイトを見かけるようにもなりました。まだまだWordPressがメインのWeb制作界隈ではありますが、これからはAstroが採用されることも増えていきそうです。

Node.jsのバージョン管理

Volta（新しいタブで開く）を使用しています。設定はpackage.jsonのvolta.nodeにあります。

Node.jsのバージョン管理ツールは色々あるので、お好きなものを使ってください。

なお、Voltaは2025年11月に「unmaintained」が宣言（新しいタブで開く）されています。このテンプレートや既存のプロジェクトでもVoltaの乗り換えを検討しましたが、Volta公式が当面の間は動作すると表明していること、乗り換え先でも近い将来同じような状況になるかもしれないことを加味して、しばらく様子見することにしています。Voltaのメンテナーは代替としてmise（新しいタブで開く）を推奨しているので、今から新しいプロジェクトを始めるならVoltaではなくmiseを採用した方がよさそうです。

パッケージマネージャー

npm（新しいタブで開く）を使っています。

pnpm（新しいタブで開く）を使ってもよいと思います。個人的にはできるだけ公式が提供するものを採用したいと思っているのでnpmを採用しています。

Node.jsのバージョン管理ツール同様、お好きなものをお使いください。

セキュリティ

ここでは依存パッケージの定期的な更新とサプライチェーン攻撃対策の2点について書きます。

依存パッケージの定期的な更新

依存パッケージのバージョンは適宜アップデートする必要があります。脆弱性のあるバージョンを使い続けると、セキュリティ上のリスクになるからです。

依存パッケージの定期的な更新のため、このテンプレートではRenovate（新しいタブで開く）を使っています。同じような機能のサービスとしてDependabot（新しいタブで開く）がありますが、Renovateの方がより細かい設定が可能です。

Renovateは依存パッケージの更新の有無を監視し、更新があればアップデートのためのプルリクエスト（新しいタブで開く）を自動で生成してくれます。

設定ファイルはrenovate.jsonです。基本的にはconfig:best-practicesのままですが、以下の設定を追加しています。

  • プルリクエストは常に1つだけにする
  • メジャーアップデートは承認制にする
  • npmパッケージとGitHub Actionsのバージョンアップには7日間のクールダウン期間を設ける（「サプライチェーン攻撃対策」にて詳述）

Renovateが作るプルリクエストを常に1つだけにしているのは、CIを節約するためです。

メジャーアップデートは承認制にしています。Renovate管理用のissueで明示的に指示しない限り、メジャーアップデートのプルリクエストは作成されません。他の依存との兼ね合いで公開直後にメジャーアップデートできないケースがたまにあるので、任意のタイミングでアップデートできた方が便利だからです。

サプライチェーン攻撃対策

昨今、リポジトリや管理者のアカウントを乗っ取りパッケージに悪意のあるコードを紛れ込ませて利用者に害を与える「サプライチェーン攻撃」がよく報告されています。

それを受けて、このテンプレートや既存のプロジェクトにはサプライチェーン攻撃対策の設定を追加しました。具体的には以下の通りです。

  • .npmrcによるインストールの制限
  • Renovateでのバージョンアップにクールダウン期間を設定

.npmrcにはignore-scripts=trueとmin-release-age=7を設定しています。ignore-scripts=trueはpackage.jsonに定義されたライフサイクルスクリプトを実行しないようにする設定です。これにより、依存パッケージのインストール時にpreinstall・install・postinstallから任意のコードが実行されるのを防ぎます。

なお、この設定により一部のパッケージでインストール時のセットアップが動作しなくなる点に注意が必要です。このテンプレートでnpx lefthook installを手動で実行する手順にしているのはそのためです。

.npmrcのmin-release-age=7は、公開から7日間経過していないバージョンのインストールを拒否します。また、RenovateでもnpmパッケージとGitHub Actionsのバージョンアップに7日間のクールダウン期間を設けています。これにより、手動のnpm installでもRenovate経由の更新でも、公開直後のバージョンは入ってきません。

なお、min-release-ageはnpm 11.10.0で追加された設定です。これより古いnpmでは指定しても無視されるので注意してください。

7日間という設定値は変更可能なので、より保守的にするなら14日間かそれ以上にしてもよいと思います。

TypeScript

現在ではTypeScript（新しいタブで開く）を使わない理由はありません。よって、このテンプレートでも採用しています。設定ファイルはtsconfig.jsonです。

astro/tsconfigs/strict（新しいタブで開く）を有効にして、あとはエイリアスを設定しているだけです。

必要に応じて変更してください。

CSS

リセットCSS、PostCSS、スタイリング手法の3点について書きます。

リセットCSS

リセットCSSとしてDestyle.css（新しいタブで開く）を使用しています。

Destyle.cssはブラウザのデフォルトのスタイルをほぼ完全にリセットします。ファイルサイズが軽量なのもよいです。

お好みのリセットCSSがあればそれに差し替えてください。

PostCSS

CSS変換ツールとしてPostCSS（新しいタブで開く）を使用しています。Astroにデフォルトで含まれているのでインストールは不要です。ルートに設定ファイルpostcss.config.jsを置くだけで有効になります。

プラグインとしてモダンなCSSの変換とベンダープレフィックスの付与をしてくれるpostcss-preset-env（新しいタブで開く）を使っています。ターゲットブラウザは.browserslistrcで指定しています。

必要なプラグインがあれば適宜追加してください。

なお、私はもうSassを使っていないのでSassのビルド環境は含まれていません。CSSの機能で十分なことが多く、もし不足があってもPostCSSのプラグインで補完できるからです。

スタイリング手法について

プロジェクトによってスタイリング手法は変えています。詳しくは「プロジェクトの特性別・CSSスタイリング手法の個人的な選び方」にてまとめているので、気になる方はそちらをお読みください。

リンター・フォーマッター

Prettier（新しいタブで開く）・ESLint（新しいタブで開く）・Stylelint（新しいタブで開く）を使用しています。設定ファイルはそれぞれ.prettierrc.json/.prettierignore、eslint.config.js、stylelint.config.jsです。

いずれも設定は最小限なので、プロジェクトに応じて適宜追加してください。

ESLintはベースの設定に加えて、import順を自動でフォーマットする設定を足しています。

Stylelintは標準的なルールを採用し、命名ルールを上書きで無効化しています。命名ルールはプロジェクトに応じて変更してください。また、プロパティの並び順のルールとしてstylelint-config-recess-order（新しいタブで開く）を使用しています。並び順のルールは他にもいくつかあるので、お好きなものをどうぞ。

Biome・Oxfmt・Oxlintについて

次世代のリンター・フォーマッターとして、Biome（新しいタブで開く）・Oxfmt（新しいタブで開く）・Oxlint（新しいタブで開く）が注目を集めています。参考として、現時点でのAstroのサポート状況をまとめておきます。

BiomeはAstroをexperimental support（新しいタブで開く）としています。

Oxlintは部分的な対応、Oxfmtは未対応（新しいタブで開く）となっています。

ともにAstroプロジェクトでは採用しづらい現状なので、このテンプレートではPrettier・ESLint・Stylelintを採用しています。

ただし、BiomeもOx系もAstroに対応しようとする動き自体はあるので、将来的にサポート対象となる可能性があります。ツールチェーンを1つにまとめられるBiomeも、高速なOx系も魅力的です。今後のサポート状況の変化は注視しておきたいですね。

EditorConfig

EditorConfig（新しいタブで開く）はエディター間での書式を統一するためのツールです。設定ファイルは.editorconfigです。

設定値は標準的なものです。必要であれば変更してください。

テスト

このテンプレートには含まれていませんが、実際のプロジェクトではテストを書くことが多いのでここで紹介します。

個人的には純粋関数は別ファイルとして切り出して、テストも用意しておきたいです。テストはあるに越したことはないので。Astroは複数のメジャーなテスティングフレームワークをサポートしていますが、現在ではVitest（新しいタブで開く）を採用しておけば間違いないと思います。

AstroでE2Eテストをしたくなるシチュエーションはあまり思いつかないのですが、もしやるとしたらPlaywright（新しいタブで開く）がいいかなと思います。

両方ともAstroの公式ドキュメント（新しいタブで開く）にセットアップ方法が記載されているので、それを参照してください。

Gitフック

Lefthook（新しいタブで開く）で管理しています。設定ファイルはlefthook.ymlです。

コミット時にステージしたファイルへリント・フォーマットをかけ、自動修正できなかった場合はコミットをキャンセルします。また、同時にastro checkも走らせ、エラーがあれば同様にコミットをキャンセルします。

プルリクエスト作成時のCIでも同じようなことができますが、コミット前に見つけられるとより便利なのでそうしています。

CI

.github/workflows/ci.ymlにCIワークフローを用意しています。mainブランチへのプッシュやプルリクエストの作成・変更でトリガーされ、リント・型チェック・ビルドを実行します。

Astroのキャッシュはデフォルトでnode_modules内につくられるため、npm ciするとnode_modulesが削除されてキャッシュが利用できなくなります。そのため、astro.config.mjsのcacheDirでAstroのキャッシュの保存場所を.astro-cacheに変更し、ワークフロー内でそれを利用するようにしています。このあたりはもっとスマートな方法があるかもしれません。

なお、実際の開発ではテスト環境や本番環境へのリリースのためのワークフローも用意します。

デプロイ先

このテンプレートには含まれませんが、参考としてデプロイ先についても書いておきます。

個人的にデプロイ先はCloudflare Workers（新しいタブで開く）のStatic Assetsを利用することが多いです。

Vercelと違い商用でも無料で利用可能で、無料枠が大きいのが選択の理由です。また、簡単なバックエンドであればWorkersとして手軽に実装できる点もメリットです。

なお、Cloudflare Pagesは現在も利用可能ですが、公式はWorkersを利用するようアナウンスしている（新しいタブで開く）点に注意してください。

まとめ

本記事では、自作のWeb制作用Astroテンプレートを改めて紹介しつつ、その技術選定の理由を書きました。

まとめると、以下のような構成です。

  • フレームワークはAstro。コンテンツメインのWebサイトでは現在も最有力
  • Node.jsのバージョン管理はVolta、パッケージマネージャーはnpm。このあたりは好みで差し替えてよい部分
  • Renovateと.npmrcの設定で、依存パッケージの更新とサプライチェーン攻撃対策
  • CSSはDestyle.cssとPostCSSだけ。スタイリング手法はプロジェクトごとに選ぶ
  • リンター・フォーマッターはPrettier・ESLint・Stylelint。Biome・Ox系ツールはAstro対応待ち
  • LefthookとGitHub Actionsで、コミット前とプルリクエストの二段構えでチェック
  • デプロイ先はCloudflare Workersが多め。商用でも無料で使えるのが理由

3年前に公開したときと比べると、CIやサプライチェーン攻撃対策など、当時は入れていなかったものも増えました。

このテンプレートは今後もメンテナンスしていくので、Web制作でAstroを使う方は参考にしてみてください。