[pull] main from withastro:main#597
Merged
Merged
Conversation
Co-authored-by: Armand Philippot <git@armand.philippot.eu>
) The astro:head-metadata-build plugin had an unfiltered transform hook that ran on every module in the build to scan source code for the "use astro:head-inject" directive. In HiDeoo's Starlight PLUGIN_TIMINGS report, this plugin consumed 36% of total plugin time during builds. The directive only appeared in two places we control: 1. ?astroPropagatedAssets modules (content render entries) — already identified by the PROPAGATED_ASSET_FLAG query param on their module ID 2. The virtual astro:content module (templates/content/module.mjs) — already has propagation: 'in-tree' set directly on module metadata in the load hook Replaced the source-scanning approach with an ID-based check for PROPAGATED_ASSET_FLAG in generateBundle. This eliminates the unfiltered transform hook entirely — Rolldown no longer needs to route every module through the JS plugin hook boundary for this plugin. Also applied the same change to the dev plugin's transform hook (astro:head-metadata) for consistency, and removed the now-unused hasHeadPropagationCall function and its test file. Manual verification with examples/blog confirmed: - CSS from components imported in MDX content appears on the individual post page - CSS does not bleed onto the blog index page - Disabling commentPropagationSeeds showed no regression because MDX uses the metadata path (propagation: 'self' via selfPropagationSeeds), which is independent Related: 501a385 (introduced the transform hook as a workaround for Rolldown stripping directives during bundling)
… path to fix bundling issues (#17093)
…hrows (#17104) * fix(astro): preserve the original error on the skip-middleware 500 retry When user middleware throws, the error handler renders 500.astro by re-running the middleware chain, which throws again, so it retries with middleware skipped. That retry was dropping the original error, leaving Astro.props.error undefined on the custom 500 page. Carry the error through the retry so the page can show what failed. Affects the standard adapter and the astro/hono composable handlers. * Apply suggestions from code review Co-authored-by: Emanuele Stoppa <my.burning@gmail.com> --------- Co-authored-by: Emanuele Stoppa <my.burning@gmail.com>
* Move internal response metadata from headers to FetchState The low-level pages() fetch handler returned raw PagesHandler responses. PagesHandler used internal response headers like X-Astro-Route-Type and X-Astro-Reroute to communicate with later Astro routing/i18n/error handling. The full astro() handler eventually stripped those headers via prepareResponse(), but direct pages() composition could leak them to users. Move that internal metadata onto FetchState instead: - responseRouteType tracks page/fallback responses for i18n finalization - skipErrorReroute tracks responses that should bypass error-page rerouting - state.isRewriting already tracks rewrite responses for logging PagesHandler now sets FetchState metadata instead of headers. AstroHandler and I18n.finalize() read the state fields. Endpoint reroute suppression is set by PagesHandler after renderEndpoint() returns, so renderEndpoint no longer mutates response headers. The public astro:i18n notFound() helper uses getFetchStateFromAPIContext() when available and keeps a header fallback for mocked/non-Astro contexts. Also removes the unused no-op middleware header. Verified: - pnpm -C packages/astro build - test/units/fetch/index.test.ts - test/units/i18n/manual-routing.test.ts - test/units/i18n/manual-middleware.test.ts - test/units/routing/routing-app.test.ts - test/endpoint-routing.test.ts * Fix endpoint reroute and i18n header compatibility after FetchState metadata move The initial FetchState metadata refactor changed endpoint reroute behavior too broadly. Missing endpoint handlers return a null-body 404 that should still reroute to the configured 404 page; only user endpoint handlers that explicitly return a 404/500 response should opt out of error-page rerouting. Pass FetchState into renderEndpoint and set skipErrorReroute only after a user handler returns a reroutable status. This restores the previous distinction while keeping the metadata off response headers. I18n.finalize also had unit coverage for direct usage with synthetic responses carrying the legacy internal headers. Keep FetchState as the primary path, but fall back to ROUTE_TYPE_HEADER and REROUTE_DIRECTIVE_HEADER when state metadata is unset so those direct calls remain compatible. * Remove remaining internal i18n header fallback after FetchState metadata move The previous fix kept compatibility reads for X-Astro-Route-Type and X-Astro-Reroute inside I18n.finalize(). That contradicted the goal of moving internal routing metadata off response headers entirely. Remove those fallback header reads and update i18n tests to use FetchState metadata instead. The public notFound() helper now requires the FetchState-backed APIContext path and records skipErrorReroute on state rather than writing X-Astro-Reroute. * Remove obsolete Astro internal response header constants Follow up to the FetchState metadata move by deleting the unused internal response header constants and the prepareResponse stripping loop. No internal code writes or reads X-Astro-Route-Type, X-Astro-Reroute, X-Astro-Rewrite, or X-Astro-Noop anymore. Update i18n tests to use FetchState metadata instead of encoding internal state through response headers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )