Custom client path still attempts to import `@prisma/client`

[why-el]

Consider this code:

// eslint-disable-next-line import/no-extraneous-dependencies
import { PrismaClient } from "@prisma-app/client";

export const createPrismockClient = async (): Promise<{
  prismaClient: PrismaClient;
  reset: () => void;
}> => {
  const { Prisma } = await import("@prisma-app/client");
  const { createPrismock } = await import("prismock");

  const PrismockClient = createPrismock(Prisma);
  const prismaClient = new PrismockClient();

  return {
    prismaClient,
    reset: () => (prismaClient as unknown as any).reset(),
  };
};

When I follow what await import("prismock"); is doing, it is doing this: import { type PrismaClient } from '@prisma/client';, which is doing this export * from '.prisma/client/default'

but export * from '.prisma/client/default' is not a thing, because the client is not generated there. For us, It is instead in @prisma-app/client, because the output in the schema.prisma is:

output = "../node_modules/@prisma-app/client"

[why-el]

@morintd does this make sense to you? I think despite the choice to move to a custom client output (something Prisma encourages now, since they are deprecating generating the client in node_modules in V6, already out, and will ban it in V7), this library still tries to load the client as if it is node_modules.

I think this is the main culprit line.

[foxane]

Running into the same problem. It is exactly as @why-el said.
Maybe use dynamic import?

[noxify]

maybe a bit late to the party, but I had the same challenge in one of my projects.

I have found the solution in the prisma adapter for betterauth and used it as inspiration for my own implementation.

• type def: https://github.com/noxify/vorsteh-queue/blob/main/packages/adapter-prisma/types/index.d.ts
• usage: https://github.com/noxify/vorsteh-queue/blob/main/packages/adapter-prisma/src/postgres-adapter.ts#L23-L36

with this, I can support the legacy prisma-client-js ( Example ) and the new prisma-client ( Example ).

I hope this helps to find a solution.

[JQuezada0]

Running into the same issue. I've worked around it for now with some vite setup magic, but it should work for any test runner that supports global setup. Fixed in fork

const Module = require("module")
const path = require("path")

const originalRequire = Module.prototype.require

const GENERATED_PRISMA_CLIENT_PATH = path.resolve(process.cwd(), "./prisma/generated/prisma")

Module.prototype.require = function (id) {
  // Redirect @prisma/client to your generated client
  if (id === "@prisma/client") {
    // Adjust this path based on your project structure
    const redirectPath = GENERATED_PRISMA_CLIENT_PATH
    return originalRequire.call(this, redirectPath)
  }

  // Call original require for everything else
  return originalRequire.apply(this, arguments)
}

This is an example of a vite setup

import { resolve } from "path"
import { defineConfig } from "vitest/config"

export default defineConfig({
  test: {
    setupFiles: [resolve(__dirname, "./backend/db/testSetup.ts")],
    globals: true,
    environment: "node",
  },
})