import-in-the-middle fails to wrap @prisma/client ESM default.js due to ERR_INVALID_RETURN_PROPERTY_VALUE

[abhilash-sivan]

When using import-in-the-middle to hook ESM imports, Prisma’s generated client fails to load.
Specifically, when import-in-the-middle intercepts @prisma/client/default.js, Node.js throws the following error:

Error [ERR_INVALID_RETURN_PROPERTY_VALUE]: Expected string to be returned for "source" from the "load" hook, but got null

This issue prevents instrumenting or patching Prisma’s ESM client using import-in-the-middle.
Interestingly, this worked fine with Prisma version 6.15, so the problem likely surfaced with recent changes in Prisma’s ESM structure or how IITM handles ESM modules.

Steps to Reproduce:

Create a simple ESM project using Prisma (v6.16 or later).

Install import-in-the-middle.

Attempt to wrap or intercept @prisma/client.

Observe the error when the app runs.

Expected Behavior:

import-in-the-middle should be able to hook Prisma’s ESM client module (default.js) without throwing loader errors.

Actual Behavior:

Node.js throws an ERR_INVALID_RETURN_PROPERTY_VALUE because the IITM loader returns null instead of a valid source string.

Environment:

Node.js: 20.x

Prisma: 6.16.0 (works fine in 6.15.0)

import-in-the-middle: [latest]

Platform: macOS/Linux

Reproduce in sample repo: https://github.com/abhilash-sivan/prisma-iitm-test/tree/main

Debug logs

start
npx prisma migrate dev --name init && node --import=./loader.mjs index.mjs

Prisma schema loaded from prisma/schema.prisma
Datasource "db": SQLite database "dev.db" at "file:./dev.db"

Already in sync, no schema change or pending migration was found.

✔ Generated Prisma Client (v6.16.3) to ./node_modules/@prisma/client in 59ms

(node:27663) Error: 'import-in-the-middle' failed to wrap 'file:///Users/abhi/instana/test-apps/prisma-iitm/node_modules/@prisma/client/default.js'
(Use node --trace-warnings ... to show where the warning was created)
TypeError [ERR_INVALID_RETURN_PROPERTY_VALUE]: Expected string, array buffer, or typed array to be returned for the "source" from the "load" hook but got null.
at assertBufferSource (node:internal/modules/helpers:379:9)
at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:101:3)
at #translate (node:internal/modules/esm/loader:534:12)
at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:581:27)
at async ModuleJob._link (node:internal/modules/esm/module_job:154:19) {
code: 'ERR_INVALID_RETURN_PROPERTY_VALUE'
}

Question:

Could this be an issue with how import-in-the-middle handles ESM modules?
Is there a recommended way to safely wrap or intercept such ESM modules without breaking the loader contract?

[pabloerhard]

This issue should get resolved by #211