Migrate from Yarn

Yarn is a package manager, not a runtime, so most of what you are "migrating" is configuration rather than code. Both Yarn Classic and Yarn Berry describe a project with a standard package.json, and Deno reads that directly: it installs and resolves the same npm dependencies and runs your scripts. A typical Yarn project runs under Deno with no changes.

The one Yarn feature that needs a decision is Plug'n'Play, Yarn Berry's default install mode. Deno does not use PnP; it installs a real node_modules directory. That is covered below.

Run your project Jump to heading#

Install dependencies and run your entrypoint:

cd my-yarn-app
deno install
deno run main.js

deno install reads your existing package.json and resolves the same npm packages, like yarn install. It writes a node_modules directory and its own deno.lock.

On your first deno install, when there is no deno.lock yet, Deno seeds it from a Yarn Classic (v1) yarn.lock, carrying over the versions and integrity hashes you already had pinned. Yarn Berry (v2+) uses a different lockfile format that Deno does not seed from; in that case Deno resolves your package.json ranges fresh, so review deno.lock before committing it.

Scripts defined in package.json run with deno task, the equivalent of yarn run:

deno task start

If you also switch from running your app on Node to running it on Deno, expect one immediate difference: Deno is sandboxed by default. The first time your program touches the network, file system, or environment, Deno prompts for permission. Grant everything up front with deno run -A main.js to match Node's behavior, then tighten the flags later. See Security and permissions.

Yarn to Deno cheatsheet Jump to heading#

Deno also ships a formatter and linter in the box, so deno fmt and deno lint replace Prettier and ESLint with no extra dependencies.

Workspaces Jump to heading#

Yarn stores workspace globs in package.json under workspaces, and Deno reads that field directly. A monorepo like this runs as-is:

{
  "workspaces": ["packages/*"]
}

Members reference each other through the workspace: protocol in their package.json dependencies, exactly as they do under Yarn. There is nothing to convert. See Workspaces for how resolution works.

Plug'n'Play Jump to heading#

Yarn Berry defaults to Plug'n'Play, which skips node_modules and resolves packages through a generated .pnp.cjs file. Deno does not implement PnP. When you run deno install, it writes a normal node_modules directory instead, so you do not need PnP at all under Deno.

In practice this means the PnP-specific files and settings stop applying once you move to Deno:

• .pnp.cjs and .pnp.loader.mjs are no longer used. Deno resolves from node_modules.
• .yarnrc.yml resolver settings (nodeLinker, pnpMode, plugins) configure Yarn specifically and do not carry over.
• yarn patch has no built-in Deno equivalent. Vendor the dependency or keep the patch in a fork.

What to watch for Jump to heading#

• Lifecycle scripts do not run by default. If a dependency relies on an install or postinstall script (native addons, node-gyp builds), allow it per package with deno install --allow-scripts=npm:<pkg>, or manage approvals with deno approve-scripts. This is a security default, not a missing feature.

Keep going Jump to heading#

• Migrate from Node.js. If you are also moving the runtime, this covers CommonJS and ES module resolution and the Node built-ins Deno supports.
• Migrate from npm and Migrate from pnpm. The same Deno commands, with notes on each tool's workspace format.
• Dependency management. npm, JSR, and package.json workflows in detail.
• Supply chain management. deno audit, lockfile discipline, and minimum dependency age.