migrate-to-deno

# Migrating to Deno Requires Deno 2.9 or later. For general Deno usage once migrated, see the `deno` skill. ## Most Node projects already run under Deno Deno reads an existing `package.json`, resolves the same npm packages, writes a real `node_modules`, runs the same scripts, and supports `node:` built-ins. TypeScript runs with no build step. There is usually **no code to change** — only which binary you invoke. Don't start by rewriting imports to `jsr:`, swapping dependencies for Deno-specific ones, or restructuring directories. Proposing that is the most common way this goes wrong. ## Migrate in rungs Each rung is independently useful and reversible. Stop wherever suits the project; plenty of teams stop at rung 1. ### Rung 1 — Deno as the package manager only ```bash deno install ``` Reads `package.json`, resolves the same dependencies, writes `node_modules`, and creates `deno.lock` — seeded from any existing `package-lock.json`, `yarn.lock`, `bun.lock`, or pnpm lockfile, so pins and integrity hashes carry over instead of drifting. The app still runs under `node`; teammates are unaffected. Commit `deno.lock` once verified. **To back out:** delete `deno.lock` and `node_modules`, then `npm install`. ### Rung 2 — Run it with Deno ```bash deno run -A main.js # or: deno -A main.js deno task build # runs scripts.build from package.json ``` Use `-A` here. The goal is confirming the program works, not designing a permission policy — changing both at once ...