Deno 2.8: test CI, npm audit, and Node compatibility without a full migration

Hook

Deno is a JavaScript and TypeScript runtime: a program that runs JS/TS code. It is often compared with Node.js: Deno can work with npm packages too, but it has a different security model, built-in tooling, and TypeScript support without a separate setup step.

Deno 2.8 is easy to read as another release-note bundle for alternative-runtime fans. But the most useful part of this release is not a promise that you should rewrite a Node project today.

The more practical move is to add Deno 2.8 as a small trial check in CI, the automated process that runs tests and technical checks after code changes. Check the lockfile, inspect npm vulnerabilities faster, explain dependencies with deno why, and learn where improved Node compatibility helps without changing the production runtime.

Problem / Context

Teams often avoid runtime experiments because a runtime change sounds like a costly refactor. That fear is reasonable. If an app runs on Node, has production deploys, a test suite, legacy npm scripts, native packages, and lots of tiny assumptions, “let us try Deno” can sound like a shortcut to chaos.

Deno 2.8 lowers the barrier not by promising a magical migration, but by adding tools that can be tested separately:

• deno ci as an explicit reproducible install step in CI;
• deno audit --fix for semver-safe remediation of some npm vulnerabilities;
• deno why to explain why a package is in the dependency tree;
• npm-friendly CLI behavior where deno add express no longer requires an npm: prefix;
• much better Node compatibility, while still not claiming 100% compatibility.

So the useful question is not “Node or Deno?” It is “which small piece of the workflow can we test without rewriting the application?”

Why It Matters

CI usually fails because of small reproducibility problems, not grand runtime ideology. One lockfile state locally, a different cache state on the runner, a lifecycle script handled differently, a security audit that reports a vulnerability without making it obvious which dependency can move safely.

deno ci makes the install step more explicit. It expects a lockfile, removes an existing node_modules directory, and runs a frozen install. In a pipeline, that is a clear signal: if the lockfile and config drift, the job should fail loudly.

deno audit --fix targets another common pain. It does not pretend to rewrite the whole dependency tree safely. Deno’s docs describe the boundary: vulnerable direct dependencies can be upgraded to patched semver-compatible versions; major upgrades, unsupported specifier styles, and transitive cases without a clean direct-dependency path are skipped.

That restraint is useful. The tool removes the safe part of the work and leaves humans responsible for the decisions that still require judgment.

How To Do It

1. Do not start with the production runtime

The first trial should be boring. Pick a repo with package.json, a lockfile, and CI, but do not change the production command.

Start in a separate branch:

deno upgrade
deno --version
deno install

If the project depends on a local node_modules, check the mode immediately. Deno’s global cache is enough for many Deno projects, but frameworks, bundlers, and native packages often expect local node_modules.

A minimal deno.json for that situation:

{
  "nodeModulesDir": "manual"
}

This is not a “migration to Deno”. It is a way to tell Deno honestly that your Node project lives in a manual install workflow.

2. Add deno ci as a separate signal

In GitHub Actions, a trial check can look like this:

jobs:
  deno-pilot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x
      - run: deno ci
      - run: deno audit

Do not replace the main npm ci yet. Put the Deno check beside it and observe whether the lockfile/install model passes cleanly.

The success criterion is simple: deno ci passes reliably on a clean runner, and the team understands what it is validating.

3. Treat deno audit --fix as a PR generator, not autopilot

deno audit --fix belongs in a separate branch:

deno audit
deno audit --fix
git diff

If it upgrades a direct dependency within a semver-compatible range, that is a good candidate for a small PR. If it says a major upgrade cannot be fixed automatically, do not relax the constraint in a panic. That is a separate task: changelog, tests, and migration notes.

For CI, keep the check separate:

- run: deno ci
- run: deno audit --level=high

Running --fix in CI without review can create strange diffs or hide an important decision. Let CI verify; let the fix command prepare a diff for a human.

4. Explain dependencies with deno why

When an audit reports a package, teams often lose time asking “who brought this in?” Deno 2.8 adds deno why <package>, similar in role to npm explain, pnpm why, or yarn why.

Example workflow:

deno why qs
deno why body-parser

This is especially useful in PR review. Instead of saying “a transitive package is vulnerable”, you can write: this package comes through a specific direct dependency, so the options are to patch that direct dependency, wait for upstream, or plan a major upgrade.

5. Do not overstate Node compatibility

Deno 2.8 made a large Node compatibility jump: the release notes report a 76.4% pass rate against Node’s test suite. That matters. But 76.4% is not the same as “any Node project can move tomorrow”.

Good first targets:

• install and audit workflow;
• standalone scripts;
• CLI tools;
• small services without complex native dependencies;
• test jobs where results are easy to compare.

Poor first targets:

• production runtime for a critical API;
• jobs with native addons before a separate check;
• complex frameworks that rely on specific Node/npm behavior;
• deployment scripts with slow rollback.

The pilot should produce knowledge, not prove a slogan.

Anti-Patterns

• Replacing npm ci with deno ci in the main production workflow without a parallel trial check.
• Running deno audit --fix in CI as if it were a safe auto-remediation bot.
• Treating a 76.4% Node test-suite pass rate as a guarantee for your stack.
• Ignoring nodeModulesDir when tools expect local node_modules.
• Mixing install trial, security remediation, and runtime migration in one merge request.
• Taking a major dependency upgrade only because audit reported a vulnerability.
• Having no rollback to the previous install/audit workflow.

Conclusion / Action Plan

Deno 2.8 is worth attention not as a reason to rush away from Node, but as a practical toolkit for stronger CI and clearer dependency workflows.

A healthy minimum rollout:

1. choose one Node repo for the trial check;
2. add Deno 2.8 in a separate CI job;
3. run deno ci without replacing npm ci;
4. add deno audit as a security signal;
5. use deno audit --fix only for reviewed PRs;
6. explain problematic packages with deno why;
7. check nodeModulesDir and compatibility boundaries;
8. after several green runs, decide what to keep.

Official sources:

• https://deno.com/blog/v2.8
• https://docs.deno.com/runtime/reference/cli/audit/
• https://docs.deno.com/runtime/reference/continuous_integration/
• https://docs.deno.com/runtime/fundamentals/node/