Support Deno #77
Support Deno #77
Conversation
action.yml
Outdated
| if: ${{ env.PACKAGE_MANAGER == 'deno' }} | ||
| shell: bash | ||
| working-directory: ${{ inputs.path }} | ||
| run: deno task _prepare |
There was a problem hiding this comment.
I never used Deno, is this a built-in task or are users expected to define this?
There was a problem hiding this comment.
Sorry, It was late 🙏🏿 but thanks for the review and the great questions! (because it's first time to throw PR)
both _prepare and build are intentionally user-defined Deno tasks; the action just invokes them, mirroring how it calls pnpm install + pnpm run build in the Node flow.
There was a problem hiding this comment.
_prepareisn’t built into Deno.- Projects use it differently (e.g.
deno cache,deno vendor, pre-compiling Tailwind, etc.), so the action leaves the command completely up to the repo. - A typical example looks like:
{
"tasks": {
"_prepare": "deno cache --lock=deno.lock deps.ts && deno vendor"
}
}If a project doesn’t need a separate prepare step, it can simply omit the task and the line in the workflow.
There was a problem hiding this comment.
If a project doesn’t need a separate prepare step, it can simply omit the task and the line in the workflow.
Consumers of the action don't have control over this. If they use this action with Deno, this command will execute. So two things:
- Since users are expected to define this, it should be documented.
- Since this is supposed to be optional, the workflow shouldn't fail if it isn't defined, change it to
deno task _prepare || trueto ensure it ignores a task error.
Is _prepare a well-known name for this in Deno, like build is a well-known name for the script/task used to build the project?
There was a problem hiding this comment.
If a project doesn’t need a separate prepare step, it can simply omit the task and the line in the workflow.
Consumers of the action don't have control over this. If they use this action with Deno, this command will execute. So two things:
- Since users are expected to define this, it should be documented.
- Since this is supposed to be optional, the workflow shouldn't fail if it isn't defined, change it to
deno task _prepare || trueto ensure it ignores a task error.
Is _prepare a well-known name for this in Deno, like build is a well-known name for the script/task used to build the project?
There was a problem hiding this comment.
Since users are expected to define this, it should be documented.
Okay, I'll do that.
Since this is supposed to be optional, the workflow shouldn't fail if it isn't defined, change it to deno task _prepare || true to ensure it ignores a task error.
I'll update the action step to
deno task _prepare || echo "no _prepare task defined, skipping"
Is _prepare a well-known name for this in Deno, like build is a well-known name for the script/task used to build the project?
First, I'm happy to rename and tweak it!
There isn’t a reserved task name in the Deno ecosystem (the docs call every entry “custom” Deno), but a few patterns show up in real projects:
| Task name | Typical purpose | Real-world example |
|---|---|---|
| setup | One-shot bootstrap (create .env, vendor deps, initialise DB, etc.) |
deno task setup |
| deps | Cache / update dependencies (deno cache, udd, etc.) |
deno task deps |
| prepare | Aggregate test → transpile → bundle steps before publishing | JSR package “signals” runs deno task prepare |
I think setup feels the most intuitive for “get the workspace ready”,
Proposed change
- name: setup
if: ${{ env.PACKAGE_MANAGER == 'deno' }}
shell: bash
working-directory: ${{ inputs.path }}
run: deno task ${PREP_TASK:-setup} || echo "no $PREP_TASK task defined, skipping"if you think that would be clearer for users—let me know!
There was a problem hiding this comment.
Yeah, if this preparation step is not a well-known and widely used name it would be best to make it configurable.
The default should be the same that will be generated by create-astro when targeting Deno (when that PR happens). I personally agree that setup is the better name, but I think this is more of a Deno community thing, whichever is more natural and understandable for Deno devs is what we should use.
There was a problem hiding this comment.
Sorry for the late reply 🙇♂️ and thank you so much for the thoughtful feedback! I completely agree—making the preparation step configurable is definitely the right approach.
I'll keep setup as the default for now since it's a common pattern in Deno projects, but once create-astro --deno landssuch as this , I'll update the default to match whatever task name it generates. That way, we stay consistent and intuitive for Deno users going forward.
| if: ${{ env.PACKAGE_MANAGER == 'deno' }} | ||
| shell: bash | ||
| working-directory: ${{ inputs.path }} | ||
| run: deno task build |
There was a problem hiding this comment.
I guess this one is user-defined just like the build script for npm/pnpm/yarn/bun run build. Would Deno use the script from package.json that create-astro generates or do users need to define the same astro build on something from Deno?
There was a problem hiding this comment.
Hi @Fryuni,
buildis required; it’s the Deno-side equivalent ofnpm run build.- For Astro we usually point it at the CLI via Deno’s npm compatibility layer:
{
"tasks": {
"build": "npm:astro build"
}
}- When you scaffold a new site with
create-astro --deno(incoming PR), those two tasks will be added automatically, so users won’t have to think about them.
Why not reuse the package.json script?
A pure-Deno project typically has no package.json at all, so deferring to deno task keeps everything in one place and lets us skip Node setup entirely. Deno resolves the npm: specifier internally, so we still get the real Astro CLI without needing npm install.
⚡ Summary
Adds first-class Deno support to
withastro/action, enabling projects thatuse
deno.json/deno.lockto rundeno task buildout-of-the-box.📝 Changes
deno.json(c)ordeno.lock; setsPACKAGE_MANAGER=denodeno-versioninput (default1.x)denoland/setup-deno@v2PACKAGE_MANAGER=denodeno+pnpm🔗 Related issue / discussion
Closes #65 (
good first issue: Deno support)✅ Test plan
pnpm build && act -j test-denoCI matrix
.github/workflows/ci.ymlwith{pm: [deno, pnpm]}Ref