A Deno adapter for running Astro applications on the Deno runtime.
by denolandTypeScript
Last 12 weeks · 7 commits
2 of 6 standards met
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
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.
Why Fix Deno Deploy boot crash introduced in #58. After #58, does: Deno Deploy's static module-graph analyzer is syntactic — it sees and cannot resolve the const. The JSR specifiers never enter the deploy-time module graph, so they never get pre-cached. At isolate boot, then throws: locally works because there's no explicit — the runtime fetches on demand. Deno Deploy exposes the bug where seems to be the default. The pre-#58 build avoided this via the chunk-rewriter, which substituted the shim import with literal lines — static, analyzable. #58 removed the rewriter without restoring an analyzer-friendly path. What this PR does Replaces the dynamic, var-indirected imports with a static imports in : Added test for Verification End-to-end test on Deno Deploy via a personal fork republished as : Deno Deploy preview built and served successfully: https://personal-web--tolutest-forked-adapter-j.tolu.deno.net/ Notes No new dependencies, no public API change. Tested combo: astro@6.3.3 + deno@2.x.
Why In the issue #53 surfaced again. Extra complexity with deno standard library imports was a workaround for Astro dependency on Node. Context Starting from Astro v5, I was able to run astro build and astro dev commands entirely in deno rutime. We can now dynamically import dependencies in function. Tested manually I linked this package locally with real astro codebase astro build ✅ astro dev ✅ tested dist in runtime standalone (start: true) middleware (start: false) Guidance needed @bartlomieju can you give me direction signals on 1. How to approach tests here? I'm happy to update them. I think the most important test happy path: build -> run (wonder why it missed breaking changes) 2. How do you update deno std depencies here? In this package deno.json is missing but we have deno.lock, I did run deno install but many std dependencies looked a bit old
Repository: denoland/deno-astro-adapter. Description: A Deno adapter for running Astro applications on the Deno runtime. Stars: 114, Forks: 26. Primary language: TypeScript. Languages: TypeScript (100%). License: MIT. Homepage: https://npm.im/@deno/astro-adapter Topics: astro, deno. Latest release: v0.3.0 (1y ago). Open PRs: 3, open issues: 10. Last activity: 1mo ago. Community health: 50%. Top contributors: kt3k, kwhinnery, irbull, bartlomieju, lucacasonato, lilnasy, Daniel15, florian-lefebvre, revgum, lisez and others.