Deno 2: Node.js and npm Compatibility for Existing Projects

For years the honest answer to whether you could run a real Node codebase on Deno was no. The runtime was elegant, secure by default, and TypeScript-native, but it ignored package.json, refused a node_modules folder, and expected you to rewrite imports around URLs. That was a wall most teams would not climb for an app already shipping in production.

Deno 2, released in October 2024, tears that wall down. The headline of the release is backwards compatibility with Node.js and npm: you can point Deno at an existing project and it just runs. This post walks through what actually changed and why I now treat Deno as a serious option for code I did not write from scratch.

package.json and node_modules are first-class now

The single biggest change is that Deno 2 understands the files a Node project already has. It reads your package.json, respects its dependencies and scripts, and will create and use a node_modules directory when your tooling expects one. There is no conversion step and no separate manifest to maintain.

In practice you drop into a Node repository and the familiar commands have direct equivalents. deno install reads package.json and populates node_modules, and deno task runs the scripts you already defined under the scripts field, the same way npm run does.

# An existing Node project — nothing to rewrite
deno install                 # reads package.json, populates node_modules
deno task dev                # runs the "dev" script from package.json
deno run --allow-net server.js

Deno also honors package.json fields like the type field for module resolution and engines for version constraints, and it supports private registries through your existing .npmrc file. The result is that an ESM Node app frequently runs under Deno with zero code changes.

npm, node, and jsr specifiers side by side

Deno 2 resolves three kinds of imports without any build tooling. The npm prefix pulls any of the two million-plus packages on the npm registry straight from your source, downloading on first run into a global cache. The node prefix reaches Node built-ins like fs and process, and the jsr prefix pulls from JSR, the TypeScript-native registry.

// npm packages — no install step required
import express from "npm:express@4";
import chalk from "npm:chalk@5";

// Node built-ins via the node: prefix
import { readFile } from "node:fs/promises";
import process from "node:process";

// JSR — the TypeScript-native registry
import { serveDir } from "jsr:@std/http/file-server";

One CLI replaces the whole toolchain

The part I appreciate most as a maintainer is that Deno ships a complete toolchain in a single binary. No separate Prettier, ESLint, Jest, and bundler to wire together and keep in sync. The deno command formats, lints, tests, adds dependencies, and compiles.

deno add npm:zod        # add an npm dependency
deno add jsr:@std/assert  # add a JSR dependency
deno fmt                # format JS, TS, JSON, Markdown, HTML, CSS, YAML
deno lint               # lint with Node-specific rules
deno test               # runs Deno tests AND node:test suites
deno compile --output app main.ts   # single self-contained binary

deno fmt now formats JavaScript, TypeScript, JSON, Markdown, HTML, CSS, and YAML. deno lint added Node-specific rules. deno test runs both Deno tests and node:test suites. deno compile produces a single self-contained executable, and deno task runs your package.json scripts. It is one dependency to install and upgrade instead of a dozen.

Workspaces and hybrid monorepos

Deno 2 supports monorepos through a workspace field in a root deno.json. A workspace is a collection of member folders, and crucially each member can carry either a deno.json or a package.json, so you can mix Deno-native and Node-native packages in the same repository.

// deno.json at the repo root
{
  "workspace": ["./api", "./web", "./packages/shared"]
}

That hybrid model is what makes gradual adoption realistic. You can migrate one package at a time rather than converting an entire monorepo in a single risky change. Across a workspace Deno can:

• Resolve dependencies between member packages by their scoped names.
• Run tests, formatting, and linting across every member with one command.
• Publish individual members to JSR while others stay on npm.

Long-term stability is now an explicit promise

The other thing enterprises ask for is a stability guarantee, and Deno 2 answers it. Starting with Deno 2.1 the project ships long-term support releases: critical bug fixes are back-ported for six months, and a new LTS branch is cut every six months. Paired with a heavily audited standard library published on JSR, that gives teams a predictable upgrade cadence.

Deno 2 versus Node.js at a glance

So should you switch?

Deno 2 reframes the question. It is no longer switch or stay, but how much of your existing Node stack you want to keep. Because it reads package.json, uses node_modules, and imports from npm, you can adopt it incrementally and reverse course cheaply if it does not fit.

My recommendation is pragmatic: try Deno on a small internal service or a fresh package in your monorepo. If deno fmt, deno lint, deno test, and deno compile let you delete a pile of config and dev dependencies, that simplification alone is worth the experiment, and you keep every escape hatch back to Node.