# npm, package.json, and deno.json

Deno 2 can read `package.json` and `deno.json` together. Do not delete Node configuration at the start of a migration; first make the existing project install, check, and test under Deno.

| Node workflow | Deno counterpart |
| --- | --- |
| `npm install` | `deno install` |
| `npm install lodash` | `deno install lodash` |
| `npm run dev` | `deno task dev` (package scripts also work) |
| `package-lock.json` | `deno.lock`; both may coexist during migration |
| bare `lodash` import | resolved in package.json projects; Deno-first code may use `npm:lodash` |

## Three node_modules modes

| Mode | Use case |
| --- | --- |
| `none` | new Deno projects using the global cache |
| `auto` | bundlers, Node-API, or tools require a local directory |
| `manual` | existing package.json workflows with an explicit install step |

```json
{
  "nodeModulesDir": "auto",
  "tasks": {
    "dev": "deno run --watch -N -E src/main.ts",
    "verify": "deno fmt --check && deno lint && deno check src/main.ts && deno test"
  }
}
```

Lifecycle scripts do not run unconditionally. When a dependency genuinely needs one, run `deno approve-scripts` to review and approve interactively (approvals persist to `allowScripts` in deno.json — the recommended flow since Deno 2.6); `deno install --allow-scripts=<package>` remains available for one-off approvals. Either way, re-audit whenever the lockfile changes.

<Callout type="warn" title="Do not delete lockfiles first">
Removing the npm lockfile and node_modules is the end of a migration, not the beginning. Keep a working rollback path until a Deno-first layout is proven.
</Callout>

Official references: [Dependency management](https://docs.deno.com/runtime/packages/) and [Node and npm compatibility](https://docs.deno.com/runtime/fundamentals/node/).