Bug description

The new esm runtime build encounters errors with nuxt:

[error] File URL path must be absolute
  at getPathFromURLWin32 (node:internal/url:1480:11)
  at fileURLToPath (node:internal/url:1511:35)
  at /D:/Programming/JabRefOnline/.nuxt/prerender/chunks/_/nitro.mjs:5613:32
  at ModuleJob.run (node:internal/modules/esm/module_job:273:25)
  at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:600:26)
  at async prerender (/D:/Programming/JabRefOnline/node_modules/.pnpm/[email protected]_patch_hash_23d72759be42371dc60aba05c74cca4b/node_modules/nitropack/dist/core/index.mjs:1892:44)
  at async /D:/Programming/JabRefOnline/node_modules/.pnpm/[email protected]_@azure+identity_15e2979548b74aaaf4e6dc6f800852e9/node_modules/nuxt/dist/index.mjs:4212:5
  at async build (/D:/Programming/JabRefOnline/node_modules/.pnpm/[email protected]_@azure+identity_15e2979548b74aaaf4e6dc6f800852e9/node_modules/nuxt/dist/index.mjs:6572:3)
  at async Object.run (/D:/Programming/JabRefOnline/node_modules/.pnpm/[email protected]/node_modules/nuxi/dist/chunks/build.mjs:91:5)
  at async runCommand$1 (/D:/Programming/JabRefOnline/node_modules/.pnpm/[email protected]/node_modules/nuxi/dist/shared/nuxi.VcyMLvO6.mjs:1767:16)

where the relevant code is in the generated prisma client

import * as runtime from '@prisma/client/runtime/library'
import * as path from 'node:path'
import * as process from 'node:process'
import { fileURLToPath } from 'node:url'

const __dirname = path.dirname(fileURLToPath(import.meta.url))

The reason is that nuxt poises ̀import.meta.url to be file:///_entry.js` (nitrojs/nitro#3177).

At least for vite, I would suggest to use the url import and then use this to locate the engine in getPrismaClient, i.e. something along the lines of

import queryEngineURL from './query_engine-windows.dll.node?url'

const config: runtime.GetPrismaClientConfig = {
   queryEngineURL,
   ....
}
runtime.getPrismaClient(
  config
)

By the way, the generated client files also reference the prisma schema

// file annotations for bundling tools to include these files
path.join(__dirname, 'schema.prisma')
path.join(process.cwd(), 'server/database/generated/schema.prisma')

But at least for me this doesn't exist. (Why does prisma need to know the schema in production anyway? It's also included in inlineSchema)

Severity

⚠️ Major: Breaks core functionality (e.g., migrations fail)

Reproduction

JabRef/JabRefOnline#2647 with failure at https://github.com/JabRef/JabRefOnline/actions/runs/14359021331/job/40255356792?pr=2630#step:7:307

Expected vs. Actual Behavior

Just functions fine under nuxt/nitro/vite

Frequency

Consistently reproducible

Does this occur in development or production?

Both development and production

Is this a regression?

No

Workaround

No workaround found

Prisma Schema & Queries

Not relevant

Logs & Debug Info

// Debug logs here

Environment & Setup

• Operating System: Windows_NT
• Node Version: v23.9.0
• Nuxt Version: 3.15.0
• CLI Version: 3.21.1
• Nitro Version: 2.10.4
• Package Manager: [email protected]

Prisma Version

prisma : 6.6.0
@prisma/client : 6.6.0
Computed binaryTarget : windows
Operating System : win32
Architecture : x64
Node.js : v23.9.0
TypeScript : 5.7.2
Query Engine (Node-API) : libquery-engine f676762280b54cd07c770017ed3711ddde35f37a (at node_modules.pnpm@[email protected]\node_modules@prisma\engines\query_engine-windows.dll.node)
Schema Engine : schema-engine-cli f676762280b54cd07c770017ed3711ddde35f37a (at node_modules.pnpm@[email protected]\node_modules@prisma\engines\schema-engine-windows.exe)
Schema Wasm : @prisma/prisma-schema-wasm 6.6.0-53.f676762280b54cd07c770017ed3711ddde35f37a
Default Engines Hash : f676762280b54cd07c770017ed3711ddde35f37a
Studio : 0.511.0