ブログを作るツールを新しい版に更新する前に、今のソースをそのまま使えるか確認するための比較を行いました。対象は、サイトを作るAstroの7.2.4と、更新候補の7.3.8です。
ところが、コードを検査するcheckコマンドを実行すると、更新候補だけでなく比較元の版でも、同じエラーで止まりました。これでは、新しい版に問題があるのか、検証用コピーの作り方に問題があるのか判断できません。
そこで、バージョンの違いを調べる前に、コピーを置くフォルダーと、その親フォルダーにある設定を切り分けました。比較用のコピーが動かないとき、バージョンを疑う前にどこを確認すればよいかを、この記録から整理します。
更新候補だけでなく、比較元も止まった
元のプロジェクトに変更を加えずに比べるため、同じブログのソースを2つの検証用ディレクトリへコピーしました。7.2.4を置いたコピーをbaseline、7.3.8を置いたコピーをcandidateと呼びます。Astroを動かすための依存ファイルも、それぞれの版に対応する既存のものをコピーしました。
それぞれのディレクトリから、次のコマンドを実行しました。
node_modules/.bin/astro check両方とも、同じエラーになりました。
[GenerateContentTypesError] `astro sync` command failed to generate
content collection types: Tsconfig not found astro/tsconfigs/strict.この状態で更新候補を評価しても、比較の基準になる7.2.4が動いていません。まず、両方に共通する失敗を調べる必要がありました。
「見つからない」と言われたファイルは、コピーの中にあった
エラーには、検証の設定で指定しているastro/tsconfigs/strictが見つからないとあります。ただし、実ファイルのnode_modules/astro/tsconfigs/strict.jsonは、両方のコピーに存在していました。
必要なファイルがコピーの中にあるなら、ファイルの有無に加えて、どこに置き、どの設定を使う形になっているかも確認する必要があります。今回のコピーは、別のAstroプロジェクトの中に置いていました。
parent-project/
├── tsconfig.json # extends: astro/tsconfigs/strict
└── .experiment-runtime/
├── baseline/
│ ├── tsconfig.json # extends: astro/tsconfigs/strict
│ └── node_modules/astro/tsconfigs/strict.json
└── candidate/
├── tsconfig.json # extends: astro/tsconfigs/strict
└── node_modules/astro/tsconfigs/strict.json検証用コピーだけでなく、上位のparent-projectにもtsconfig.jsonがありました。これは、TypeScriptのコード検査などに使う設定ファイルです。どちらの設定も、extendsでastro/tsconfigs/strictの設定を引き継ぐ指定になっていましたが、依存は検証用コピーにだけ用意してあり、parent-projectにはありませんでした。
以後、検証用コピーを「子」、この上位ディレクトリの設定を「親設定」と呼びます。図では、子の直上にある.experiment-runtimeより、さらに1階層上の設定です。この親設定が失敗に関わっているかを、診断用のコピーで調べました。
子を変えず、親設定だけを変えて比べた
ソースのリビジョン、Node.js、実行コマンド、環境変数は固定しました。依存は各バージョンについて同じ一式を3条件で使い、比較中の取得や再インストールはしていません。7.2.4側と7.3.8側の依存一式が同一という意味ではありません。
同じ入れ子の配置のまま、診断用コピーの親設定だけを{}にした条件を比べました。これでcheckの成否が変われば、子の設定や依存を変えずに、親設定の影響を確かめられます。もう一つの条件は、親のAstroプロジェクトの外に、同じソースと各版の依存を置いたコピーです。
| 条件 | Astro 7.2.4 | Astro 7.3.8 |
|---|---|---|
親がastro/tsconfigs/strictを継承し、親には依存がない |
exit 1 | exit 1 |
同じ配置で、診断用コピーの親設定だけを{}に変更 |
exit 0 | exit 0 |
| Astroの親プロジェクトの外に置いた独立したコピー | exit 0 | exit 0 |
表のexit 0はcheckが通ったこと、exit 1は失敗したことを示します。成功した4条件はいずれもerrors 0、warnings 0、hints 18でした。hintsは、エラーや警告とは別に表示される参考メッセージです。
1行目から2行目では、子の設定と依存を変えず、親設定だけで成否が変わっています。この配置では、親設定が失敗に関わっていたと分かります。また、親のAstroプロジェクトの外へコピーを置いた場合も、両方のcheckが通りました。
表とは別に、親設定を元に戻し、途中のディレクトリに空のtsconfig.jsonを置く方法も試しました。しかし、両バージョンとも失敗しました。途中に空の設定を置けば、今回の影響を避けられるという結果にはなりませんでした。
node_modules配下への配置は、7.2.4だけの確認です。checkは通りましたが、保存した要約ではhintsが286件でした。他の成功条件の18件と結果が変わっているため、同じ条件での修正とは扱わず、採用していません。7.3.8では試していません。
検証用コピーが止まるとき、上位の設定まで確認する
バージョン比較や一時的な検証のために、既存プロジェクトの中へ別のコピーを置くことがあります。そのコピーで設定が見つからないと言われたら、コピーの中のファイルと、その上位にある設定を両方確認するのが、この事例で役立つ確認です。
上の図のbaseline/またはcandidate/から調べるなら、次のようになります。
pwd
cat tsconfig.json
ls -l node_modules/astro/tsconfigs/strict.json
cat ../../tsconfig.json
ls -ld ../../node_modules/astro最初の3つで、実行場所、子の設定、子にある依存ファイルを確認します。後半の2つで、親の設定と親にAstroの依存があるかを確認します。今回、子のstrict.jsonは存在しましたが、親もAstro設定を継承しているのに、親のnode_modules/astroはありませんでした。
../../はこの図での位置です。別の配置なら、検証用コピーを置いた上位ディレクトリに合わせて確認先を変えます。
配置の影響を比べるときは、使い捨てのコピーでソースと各バージョンの依存を保ち、親設定または配置を変えてcheckの成否を記録します。親設定を{}にしたのは原因を切り分けるためで、普段使うプロジェクトの設定を消す修正ではありません。今回は、親のAstro設定から分離した配置で比較元と更新候補の両方が通り、更新を比べるための検証を始められる状態になりました。
checkが通っても、更新の判断はここで終わらない
この記録の表は、2026年10月11日にmacOS 27.0.1／arm64、Node.js v24.19.0で行った、3条件×2バージョンのcheck比較です。各条件1回なので性能差は判断せず、この6条件では、サイトを生成するbuildと、その生成物も確認していません。
親設定の影響は確認しましたが、Astro・Vite内部のどの実装がその設定を取り込むかは特定していません。また、独立配置でcheckが通ったことだけで、Astro 7.3.8全般の互換性やアップグレードの可否を判断することもできません。今回得られたのは、バージョンを評価する前に、比較元まで止まる検証環境をどう切り分けたかという結果です。
検証記録には、ソースのリビジョン、主要ファイルのハッシュ、環境変数、6条件の終了コードと所要時間、表外の試行の要約を残しています。依存一式の入手手順を含む再現用パッケージではありません。