feat(astro)!: Drop Astro 3 support#22553
Conversation
Raises the minimum supported Astro version to 4. The v11 migration guide already declared this; this change makes the code and package metadata follow through. - Raise `astro` peerDependency floor to `>=4.0.0-beta` and build/test against Astro 4 (`devDependencies.astro` -> `^4.16.19`). - Migrate the `MiddlewareResponseHandler` type import to `MiddlewareHandler`. Astro removed `MiddlewareResponseHandler` in v4; in v3 it was `MiddlewareHandler<Response>`, in v4+ `MiddlewareHandler` is non-generic and identically shaped. - Remove the `supportsAddMiddleware` guard; `addMiddleware` was introduced in astro@3.5.0 and is always present on the Astro 4+ floor. - Align `devDependencies.vite` to `^5.4.11` to match the vite version Astro 4 resolves to, avoiding a nested-vite type mismatch in the Cloudflare plugin path. - Drop Astro <3.5.2 manual-middleware docs and version-specific comments. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| version "0.18.20" | ||
| resolved "https://registry.yarnpkg.com/esbuild/-/esbuild-0.18.20.tgz#4709f5a34801b43b799ab7d6d82f7284a9b7a7a6" | ||
| integrity sha512-ceqxoedUrcayh7Y7ZX6NdbbDzGROiyVBgC4PriJThBKSVPWnnFHZAkfI1lJT8QFkOwH4qOS2SJkS4wvpGl8BpA== | ||
| esbuild@^0.21.3, esbuild@^0.21.5: |
There was a problem hiding this comment.
Medium severity vulnerability may affect your project—review required:
Line 15870 lists a dependency (esbuild) with a known Medium severity vulnerability.
ℹ️ Why this matters
Affected versions of esbuild are vulnerable to Origin Validation Error. esbuild's development server responds to every request, including Server-Sent Events connections, with Access-Control-Allow-Origin: *. Any website a developer visits can therefore make cross-origin requests to the local dev server and read the responses, leaking bundled source code, source maps, and served file paths. Starting the dev server via serve() reaches the vulnerable code path.
References: GHSA
To resolve this comment:
Check if you run esbuild with the --serve flag to start the development server.
- If you're affected, upgrade this dependency to at least version 0.25.0 at yarn.lock.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| @@ -29941,7 +29837,18 @@ vite@^4.4.9: | |||
| optionalDependencies: | |||
| fsevents "~2.3.3" | |||
|
|
|||
| vitefu@^0.2.2, vitefu@^0.2.4, vitefu@^0.2.5: | |||
| vite@^5.4.11: | |||
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 29840 lists a dependency (vite) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of vite and vite-plus are vulnerable to Exposure of Sensitive Information to an Unauthorized Actor / Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). Vite's server.fs.deny blocklist—which protects sensitive files such as .env and certificate files from being served—can be bypassed on Windows using alternate path representations (NTFS Alternate Data Stream syntax like /.env::$DATA?raw, or 8.3 short filenames), allowing an attacker to read otherwise-denied files when the dev server is exposed to the network.
To resolve this comment:
Check if you expose the Vite dev server or vite-plus to the network by configuring a non-loopback address using the --host CLI flag on Windows.
- If you're affected, upgrade this dependency to at least version 6.4.3 at yarn.lock.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
Raises the minimum supported Astro version to 4.
MIGRATION.mdalready declares "Astro: dropped Astro 3 (minimum is now 4)" for v11, but the@sentry/astrocode and package metadata never followed through — this change closes that gap.Changes
packages/astro/package.json): peer floor raised to>=4.0.0-beta, dev dep bumped to Astro^4.16.19. The peer range keeps the>=7.0.0-betadisjunct so Astro 7 prereleases still resolve; the redundant>=4.0.0term was dropped since>=4.0.0-betaalready covers it.MiddlewareResponseHandler→MiddlewareHandler(server/middleware.ts): the one genuinely Astro-3-only code artifact. Astro removedMiddlewareResponseHandlerin v4 — in v3 it wasMiddlewareHandler<Response>, in v4+MiddlewareHandleris non-generic and identically shaped.supportsAddMiddlewareguard (integration/index.ts):addMiddlewarewas introduced in astro@3.5.0, so it is always present on the Astro 4+ floor.types.ts/middleware/index.ts.Decisions
vitedev dep dropped from^6.4.3to^5.4.11.cloudflare.tsimportsPluginfrom the package's hoisted vite, while Astro'supdateConfig({ vite })field is typed against Astro's own vite copy. Astro 4 depends onvite ^5, so with a vite-6 dev dep yarn installs a nested vite 5 undernode_modules/astroand the two copies mismatch (Plugin<any>not assignable toPluginOption). This skew always existed but was harmless against Astro 3's vite 4 (looser types); vite 5 is stricter. Aligning the dev dep to vite 5 makes both sides resolve to the same copy. Building against Astro 5 instead was rejected because Astro 5 removed thehybridoutput mode still referenced in the integration; casting the plugins was rejected in favour of matching the floor.addMiddlewarebeing absent in unrelated SSR-mode tests (vercel assets glob, all ofcloudflare.test.ts). Fixed by addingaddMiddleware: vi.fn()to the sharedbaseConfigHookObjectin both test files, reflecting reality — Astro 4+ always provides it.Not affected (verified)
interpolateRouteFromUrlAndParamsfallback and theSymbol.forroute-manifest casts are for Astro 4/5/6, not v3 — left as-is.🤖 Generated with Claude Code