deno-astro-adapter

Small CI hardening: declares an explicit workflow-level on 1 workflow(s) that currently inherit the default broad read-write GITHUB_TOKEN. I inspected each file before including it; none publish, push, comment on issues/PRs, or otherwise write via the GitHub API, so the read-only default does not change behavior. Workflows that need to write (stale, release, gh-pages-deploy, publish actions, etc.) are intentionally left out of this PR. This is the post-CVE-2025-30066 hardening pattern for default token scope.

I was working on improving page speed for my application. In the middle of shifting various components to server islands and making certain pages pre-rendered, along with fixing various headers, Claude Sonnet 5 found this issue. If anyone else hits this issue while it still exists, the fix is to either create your own server.js, or use something like Cloudflare's caching rules to set the cache-control headers. I had Claude writeup a summary on this. Summary On a project using with per-page opt-in prerendering (), any response headers set via during the page's frontmatter are silently discarded for the built static file. The served response only carries whatever headers Deno's file server attaches by default (, , ) — never the app's own headers. This is because Astro core only forwards prerendered-page response headers to an adapter when the adapter declares (see ), and never sets this flag, nor implements the hook that would let it consume the resulting map. Other official adapters (Vercel, Netlify) implement this to persist such headers into platform-specific static config (, a Netlify -equivalent). Environment : 0.5.2 : 6.4.8 , with several routes individually opted into deno 2.9.1 (stable, release, x86_64-unknown-linux-gnu) typescript 6.0.3 Repro steps 1. In an project using , create a page with: 2. , then serve the build with the adapter's generated entrypoint (, i.e. the /production server path). 3. Request the page and inspect response headers. Expected is present on the response, matching what was set in the page's frontmatter. Actual No header is present at all. The response only carries whatever 's sets by default (confirmed via : only and a weak ). Root cause Two pieces, one in Astro core (working as designed, gated behind an adapter opt-in) and one in this adapter (the opt-in is never made): 1. Astro core captures the headers, but only forwards them if the adapter opts in. (the actual headers set via during the prerender pass) is captured locally, but only stored into — and thus only ever exposed to an adapter via the integration hook — when is . See also the type declaration at () and the adapter reference docs: https://docs.astro.build/en/reference/adapter-reference/#staticheaders 2. never sets this flag, and has no hook. , in the hook: There's no here (note: distinct from , which is a different, unrelated field), and grepping the package source turns up zero references to or anywhere. 3. The runtime effect of the missing feature.** , in the request handler: A prerendered route isn't in Astro's on-demand route manifest, so returns nothing for it, and the handler falls through to serving the pre-built file straight off disk via — a plain static file server with no knowledge of any headers the page's frontmatter tried to set at build time. Suggested fix In 's call, add . Implement the hook to receive , and persist it somewhere the runtime in can read when serving a static file — e.g. write a small headers manifest into the build output (alongside the client assets) at build time, and have the branch in look up and apply the corresponding entry before returning the response. References https://docs.astro.build/en/reference/adapter-reference/#staticheaders Vercel's implementation for comparison: https://docs.astro.build/en/guides/integrations-guide/vercel/#staticheaders Netlify's implementation for comparison: https://docs.astro.build/en/guides/integrations-guide/netlify/#staticheaders

Changes [x] Update to latest: , , , , , [x] Update bundler options (needed for , part of now): -> (see https://vite.dev/guide/migration#other-related-deprecations) [x] ~~Add to resolve the imports properly, especially to avoid errors such as:~~ [x] Remove from server path (it's not needed anymore and it would produce a wrong path instead) Test project This PR has been tested locally by running a basic Astro 7 project: Select "A basic, helpful starter project" and follow all other steps. into test project folder Add by linking in (see Deno docs -> Use local and unpublished packages) Update (see README) Update (see README) Run the project Verify Deno version: Note ~~There is an issue in Deno 2.9 (build from source only) by rendering broken images in SSR projects - see https://github.com/denoland/deno/issues/35648~~ ~~And there is already a fix https://github.com/denoland/deno/pull/35649~~ ^ Merged today. Closes #62