Setting the file. One moment.
Subchapter 5.4
references/FROM_YARN.mdMarkdown3 KBView on GitHub
Yarn is a package manager, not a runtime, so the migration is configuration
rather than code. Deno reads the existing package.json, installs the same
dependencies, and runs the same scripts.
| Yarn | Deno |
|---|---|
yarn install | deno install |
yarn add <pkg> | deno add <pkg> |
yarn add -D <pkg> | deno add -D <pkg> |
yarn remove <pkg> | deno remove <pkg> |
yarn <script> | deno task <script> |
yarn dlx <pkg> | dx <pkg> |
yarn why <pkg> | deno why <pkg> |
yarn workspaces foreach | deno task --filter '*' <script> |
Classic (v1) and Berry (v2+) diverge on the rest, so the mapping is not uniform. Deno has one spelling regardless of which the project came from:
| Task | Yarn Classic (v1) | Yarn Berry (v2+) | Deno |
|---|---|---|---|
| CI install | yarn install --frozen-lockfile | yarn install --immutable | deno ci |
| Outdated | yarn outdated | removed | deno outdated |
| Audit | yarn audit | yarn npm audit | deno audit |
Deno does not implement PnP; it creates a conventional node_modules.
.pnp.cjs and .pnp.loader.mjs become unused. Delete them once migrated..yarnrc.yml resolver settings (nodeLinker, pnpMode, registry mirrors) do
not transfer.yarn patch has no equivalent. Vendor the dependency or maintain a fork.If the project relied on PnP’s strictness to catch undeclared dependencies,
Deno’s isolated layout gives similar protection: real files in
node_modules/.deno/, exposed through symlinks.
yarn.lock seeds deno.lock, preserving pins."workspaces": ["packages/*"] works unchanged; members reference each other
through the workspace protocol with no conversion.
resolutions is not supported. Pin through an import map entry instead:
{
"imports": {
"lodash": "npm:lodash@^4.17.21"
}
}Don’t run by default. Approve per package with deno approve-scripts or
deno install --allow-scripts=npm:<pkg>.