Prisma instrumentation no longer works on >5.9.0

[bizob2828]

Description

Prisma just released 5.9.0. It looks like they restructured exports to where instrumenting @prisma/client is not sufficient.

Expected Behavior

Instrumentation of prisma 5.9.0+ will still function

Steps to Reproduce

cd test/versioned/prisma
npm i prisma@latest @prisma/client@5.9.0 --no-save --no-package-lock
node prisma.tap.js

Additional context

This will be an exercise in figuring out the appropriate paths to give to shimmer.registerInstrumentations. I've tried the following so far and it's very hard to determine the right paths. WIP branch

You can see the export changed

5.8.1 with debug on in require-in-the-middle

2024-01-30T16:54:52.135Z require-in-the-middle resolved filename to module: @prisma/client (id: @prisma/client, resolved: @prisma/client, basedir: /Users/revans/code/release/node-newrelic/test/versioned/prisma/node_modules/@prisma/client)
2024-01-30T16:54:52.136Z require-in-the-middle calling require hook: @prisma/client

5.9.0

2024-01-30T16:39:22.506Z require-in-the-middle resolved filename to module: @prisma/client (id: @prisma/client, resolved: @prisma/client/default, basedir: /Users/revans/code/pull-requests/node-newrelic/test/versioned/prisma/node_modules/@prisma/client)
2024-01-30T16:39:22.506Z require-in-the-middle ignoring require of non-main module file: /Users/revans/code/pull-requests/node-newrelic/test/versioned/prisma/node_modules/@prisma/client/index.js

[workato-integration]

https://new-relic.atlassian.net/browse/NR-220054

[jsumners-nr]

The issue stems from prisma/prisma@9c14954#diff-26d3d28d31824ef26252df77cca08d24faea8451cb8fd3ffee2000f9e496daa0 introduced by PR prisma/prisma#22630.

[millsp]

In order to find out what went wrong, I created a minimal reproduction to try and understand how your tests were failing. Thanks to the context you left in this issue and elsewhere, I took a look at how you were resolving and injecting the Prisma Client. Then I came up with this reproduction:

// index.ts

import { Hook } from 'require-in-the-middle' 

new Hook(['@prisma/client'], {
}, function (exports, name) {
  console.log('loading %s', name) 

  return exports
})

require('@prisma/client')

With prisma@5.8.0 it produced the following output:

$ node -r esbuild-register index.ts

loading @prisma/client

With prisma@5.9.0 it produced no output at all:

$ node -r esbuild-register index.ts

Somehow according to Hook, nothing was loaded, and that's obviously not true. To investigate, I then passed internals: true as a Hook option, that surprisingly made it display something, so it seemed like I hit a bug or an edge case?

new Hook(['@prisma/client'], {
  internals: true
}, function (exports, name) {
  console.log('loading %s', name) 

  return exports
})

$ node -r esbuild-register index.ts

loading @prisma/client/runtime/library.js
loading @prisma/client/default.js

Further down, I tried to understand why this would be an edge case if other libraries like xstate or preact seemed to work just fine with Hook. After proceeding by elimination, I found one key difference between @prisma/client's exports map and other libs. In short:

The main field in @prisma/client was pointing to index.js while the exports was pointing the default to default.js. To my surprise this was the reason. I pointed main to default.js as well and Hook started working again. We do need to have different index.js and default.js files though.

[millsp]

After taking a look at the source code of require-in-the-middle, it does expect the resolved exports and main to be the same unless you specify internals, so that confirms what I observed. Given this behavior, this is how I would do it:

import { Hook } from 'require-in-the-middle' 

async function main() {
  new Hook(['@prisma/client/default'], {
    internals: true
  }, function (exports, name, basedir) {
    console.log('loading %s', name) 

    return exports
  })

  require('@prisma/client')
}

void main()

Let me know if that works for you.

[bizob2828]

@millsp thanks for taking time to triage and fix. We do not pass internals: true to require-in-the-middle for "reasons". However I was able to determine 5.10.0-integration-fix-client-exports-map.4 fixes our issues with no changes. do you plan on releasing this in 5.10.0? or a 5.9.1? How I tested was

cd test/versioned/prisma
npm i prisma@latest @prisma/client@5.10.0-integration-fix-client-exports-map.4 --no-save --no-package-lock
node prisma.tap.js

[millsp]

Happy that we found a solution, and thanks for confirming the fix.
We are planning to release this via 5.9.1 once the PR is ready.

[bizob2828]

This issue will serve to update the version ranges for our prisma versioned tests and just skip 5.9.0