nekowinston/setup-deno

🦕 Deno Setup action with integrated cache

setup-deno

Deno Setup action with integrated cache.

• Based on:
  • denoland/setup-deno@v1,
  • actions/cache@v4
• Handles restoring and caching to DENO_DIR for you.
• Annotates your source code from deno lint --compact output.
  See the summary of the most recent Problem Matcher worflow for an example.
• Works on Ubuntu, macOS & Windows runners.

Usage

Basic:

- uses: nekowinston/setup-deno@v1

All options:

- uses: nekowinston/setup-deno@v1
  with:
    deno-version: "~1.38"
    deno-json-path: ./subdirectory/deno.json
    deno-lock-path: ./subdirectory/deno.lock
    directory: ./subdirectory

Inputs

• deno-version:
  The Deno version to install. Can be a semver version of a stable release, 'canary' for the latest canary, or the Git hash of a specific canary release.
  See setup-deno for examples.
  Defaults to 1.x.
• deno-json-path:
  The path to the Deno config file to use for caching.
  Defaults to an empty string, using the built-in CLI default.
• deno-lock-path:
  The path to the lock file to use for caching.
  Defaults to ./deno.lock.
• directory:
  The path to the scripts to cache. This can be useful if Deno is only part of your repo, and stored in a subdirectory.
  Defaults to the repo root.

Outputs:

• deno-version: The Deno version that was installed.
• is-canary: If the installed Deno version was a canary version.
• cache-hit: A boolean value to indicate an exact match was found for the key.

setup-deno's Issues

Use JS glob + ignore for the cache glob step

The current find ${{ inputs.directory }} -regex '.*\.[jt]sx*' -exec deno cache {} \; stuff is pretty... gross.
I'd like to make picking the files which deno caches more customizable and intuitive.

Ideally, this would be handled by the deno binary itself; e.g.:

Repo layout:

/
├── test/
│   ├── basic/
│   │   └── main.ts*
│   ├── customized/
│   │   ├── deno.json
│   │   ├── deno.lock
│   │   └── main.ts
│   └── problem-matcher/
│       ├── deno.json
│       ├── deno.lock
│       ├── foo.ts
│       ├── foo_test.ts
│       └── main.ts
├── .denoignore
└── deno.json

.denoignore:

test/problem-matcher
!test/problem-matcher/foo.ts

$ deno cache
-> caching test/basic/main.ts
-> caching test/customized/main.ts
-> caching test/problem-matcher/foo.ts

---

Working around the fact that this isn't supported by the binary, we could create a script that works in both Node (for actions) and Deno (for the dev), which effectively does this. The dev could add this script to the deno.json like

{
  "tasks": {
    "cache": "deno run -A https://esm.sh/gh/nekowinston/setup-deno/cache.ts"
  }
}

Which then calls deno cache on each file in the glob pattern, storing it in deno.lock.
The Node script would have the same files in its match, with improved customizability compared to just a single action input for a directory.