3 Replies
You selected the bot's instantaneous insights. Let me compile your answer right away!
You’re hitting a known Prisma 6/7 + Next.js/Webpack issue: the new
provider = "prisma-client" generator emits TypeScript files (client.ts, internal/class.ts, enums.ts, internal/prismaNamespace.ts) but the generated client.ts imports them as ESM .js files:
Since only .ts files exist at that point, Webpack (used by Next.js) can’t resolve these .js imports and you get exactly the Can't resolve './internal/class.js' / './internal/prismaNamespace.js' / './enums.js' errors. [Prisma 7 Webpack; Generated imports .js]
This is a Prisma bug/regression with the TypeScript-output client and custom output paths / bundlers like Webpack/Next.js. [Incorrect imports; NextJS - Prisma]
From the sources, there are only workarounds, no clean built‑in fix yet:
1. Use CommonJS client instead of the TS ESM-style client
In schema.prisma:
Then re‑generate:
This avoids the problematic .js imports in .ts files. [Prisma 7 ESM fix]
2. (Less ideal, per issues) Add a bundler step that compiles those TS files to JS and import from the compiled location (e.g. via tsc or Webpack config alias), but this is explicitly noted as clunky in the reports and can still fail in Next.js. [Client.js workaround; [Next.js Webpack fail](<https://github.com/prisma/prisma/issues/28627>)]
Given you’re on Next.js, the most reliable workaround from the shared issues is switching to
moduleFormat = "cjs" for now and regenerating the client.
🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.