setup-deno

Why it's ranked here

This is a focused choice for Deno automation because it handles both ordinary pinned releases and less common channels through one configuration surface. Version and release-channel outputs help later steps inspect what was installed. Built-in installation and dependency caches address repeated downloads, though version resolution still depends on remote Deno services.

What's good

Version selection is unusually flexible: exact releases, semantic ranges, channels, commit hashes, and version files all work. It supports renamed binaries for side-by-side installations. Dependency caching uses the job, runner operating system, architecture, and project lock data, while allowing callers to replace the project hash.

Tradeoffs

Supported runners are limited to Linux, macOS, and Windows on x64 or arm64. Stable range resolution and moving channels require network access to Deno release services. Dependency caching needs matching Deno directory configuration across relevant steps. The default version is a moving major range, so reproducibility requires an explicit pin.

How to use it well

Use it in GitHub Actions jobs that need a predictable Deno executable before linting, testing, building, or publishing. Pin an exact release when repeatability matters, and enable dependency caching when jobs repeatedly fetch the same locked modules. It installs and caches Deno, but it does not define or execute your project checks or deployment process.

Observed

License

MIT

Primary language

TypeScript

Packaging

GitHub Action executed with the Node 24 runtime

Interface

Workflow inputs for version, version file, binary name, dependency caching, and cache hash

Outputs

Cache hit status, installed Deno version, and release channel

Platform support

Linux, macOS, and Windows on x64 or arm64