This isn't really a Prisma issue, it's the moduleResolution: "bundler" setting doing what it's supposed to.

bundler is designed for bundler-driven workflows (Vite, esbuild, webpack). Under that setting, TypeScript accepts extensionless imports and does not rewrite them on emit. Node.js ESM at runtime requires explicit .js extensions for relative imports, and since nothing in the build adds them, Node throws ERR_MODULE_NOT_FOUND on every first-party import the moment you run the compiled output.

Three ways to fix it, pick one:

1. Run TypeScript directly with tsx (simplest for the Prisma quickstart)

npx tsx src/index.ts

No build step, no resolution mismatch. This is what most starter projects use.

2. Switch to nodenext

{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "nodenext",
    "target": "ES2023",
    "strict": true,
    "esModuleInterop": true
  }
}

With nodenext, TypeScript requires .js extensions in your imports (import { foo } from './bar.js'), the emitted code then runs on Node without rewrites. Note: this only affects your own imports; the generated Prisma client works either way.

3. Compile to CommonJS

{
  "compilerOptions": {
    "module": "CommonJS",
    "moduleResolution": "node",
    "target": "ES2023",
    "strict": true,
    "esModuleInterop": true
  }
}

Easiest for short scripts since CJS resolution doesn't care about extensions.

Summary: moduleResolution: "bundler" isn't meant for code that runs directly via node. Use tsx to run TS, or switch both module and moduleResolution to a Node-compatible pair and the Prisma client imports will resolve cleanly too.