create-t3-turbo: Prisma broken for next when generating prisma client in non-node_modules dirs

Using the changes from @subaanqasim got things running for me (very appreciated) locally.

When I run the deploy, I see this:

@padelstripes/db:db-generate: > @padelstripes/db@0.1.0 db-generate /vercel/path0/packages/db
@padelstripes/db:db-generate: > prisma generate
@padelstripes/db:db-generate: 
@padelstripes/db:db-generate: Prisma schema loaded from prisma/schema.prisma
@padelstripes/db:db-generate: 
@padelstripes/db:db-generate: ✔ Generated Prisma Client (4.5.0 | library) to ./../../node_modules/.prisma/client in 255ms
@padelstripes/db:db-generate: You can now start using Prisma Client in your code. Reference: https://pris.ly/d/client
@padelstripes/db:db-generate: ```
@padelstripes/db:db-generate: import { PrismaClient } from '../../node_modules/.prisma/client'

However, the API calls return:

ERROR	Error: @prisma/client did not initialize yet. Please run "prisma generate" and try to import it again.
In case this error is unexpected for you, please report it in https://github.com/prisma/prisma/issues

Seems like either the db package is looking in the wrong place, or the generation output is going maybe two levels up from the root and out of the project?

Anyone hit on anything like this?

Yeah, fair enough - I figured it’s worth mentioning here in case someone else is in a similar situation.

Hey gang - coming back to this issue since I’ve been wrestling it for a few days here. I’m building an app with create-t3-turbo, and have been trying to keep my changes roughly in sync with what’s happened in this repo since I started with it in December.

I was getting ENOENT errors from my nextjs project when trying to import prisma – and found my (current) fix in this comment - https://github.com/prisma/prisma/issues/12921#issuecomment-1414839304 - the prisma team have an experimental webpack plugin which seems to address this issue. The prisma issue was linked earlier here, but there’s been some activity since then. Figured a bump might help.

oh yeah lol, I got a ENOENT no such file error on the trpc API file pointing towards the prisma schema.

I spent a full day debugging this issue a few days ago, so I thought I’d give my two cents into how I’ve solved it (for now at least, since it’s kinda hacky). Apologies for the long post, but I thought I’d explain my thought processes in case someone with a bigger brain can produce a legit solution based off the information below.

TLDR:

1. To fix nextjs ENOENT error:

// .npmrc

public-hoist-pattern[]=*prisma*

1. To fix prisma client type inference issues:

// schema.prisma

generator client {
  provider        = "prisma-client-js"
  output          = "../../../node_modules/.prisma/client"
}

// packages/db/index.ts

import { PrismaClient } from "@prisma/client";

export const prisma = new PrismaClient({
  log:
    process.env.NODE_ENV === "development"
      ? ["query", "error", "warn"]
      : ["error"],
});

1. Ensure proper caching of prisma client following the above changes, in turbo.json:

"pipeline": {
    "db-generate": {
      "outputs": ["../../node_modules/.prisma/client"]
    }
}

---

Context: the repo I’m working with is essentially a create-t3-turbo monorepo - 2 next apps (with next-auth, but no expo), with prisma and tRPC as shared packages.

From my understanding, the ENOENT in the nextjs app is due to it trying to import the prisma client from the node_modules at the root of the monorepo. Adding public-hoist-pattern[]=*prisma* to .npmrc seems to fix that issue by seemingly hoisting the prisma client generation to the root (from https://github.com/prisma/prisma/issues/12921#issuecomment-1152901509). HOWEVER, this will only work if PrismaClient is imported from @prisma/client in db/index.ts and not from a custom generator path.

However, this then results in an issue for the tRPC api package - the imported prisma client in api/src/context.ts from will be of type any. This is despite instances of prisma imported from @acme/db in the next app resolving the types properly (currently, you’ll notice that prisma is type any in the next app and api package in create-t3-turbo due to no hoisting). If you set a custom generator path for your prisma schema and create your client from that in db/index.ts then the prisma type issues fix, but you get the ENOENT error again in the next app due to the custom path of the client not being hoisted up to the root node_modules. Humongous pain.

Importing from @prisma/client just exports the default schema generation path (node_modules/.prisma/client). In theory, according to this explanation of how pnpm and prisma client imports works, we should be able to generate the client into the root by having output = "../../../node_modules/.prisma/client" in schema.prisma and import PrismaClient from @prisma/client in db/index.ts. This is because we’re now hoisting prisma to root and generating the client in the root, so all the prisma stuff is sitting together.

Then, to ensure proper caching of the prisma client, change the db-generate output in turbo.json to the root:

"pipeline": {
    "db-generate": {
      "outputs": ["../../node_modules/.prisma/client"]
    }
}

This is what ultimately worked for me - no ENOENT errors, proper type inference of the prisma client in all packages and apps, and proper caching by turborepo.

Also, with this solution, it might be worth locking pnpm version to <7.13.5 in Vercel builds using the ENABLE_EXPERIMENTAL_COREPACK=1 env variable due to this potential issue.

Hey gang - coming back to this issue since I’ve been wrestling it for a few days here. I’m building an app with create-t3-turbo, and have been trying to keep my changes roughly in sync with what’s happened in this repo since I started with it in December.

I was getting ENOENT errors from my nextjs project when trying to import prisma – and found my (current) fix in this comment - prisma/prisma#12921 (comment) - the prisma team have an experimental webpack plugin which seems to address this issue. The prisma issue was linked earlier here, but there’s been some activity since then. Figured a bump might help.

As far as I know the ENOENT errors were fixed in this repo already, so not really sure what the issue is in your case man.

Need to sleep and come back to take a look, but these are the first set of changes that let me run dev and get through a clean build with no ENOENT issues and prisma type inference carrying through (including adding and testing a new model in prisma.schema).

/.env ENABLE_EXPERIMENTAL_COREPACK=1

/next.config.mjs:

defineNextConfig({
  webpack: config => {
    config.externals = [...(config.externals || []), '@prisma/client'];
    return config;
  }
})

/.npmrc (I removed node-linker=hoisted and public-hoist-patter[]=*prisma*

strict-peer-dependencies=true
auto-install-peers=true
link-workspace-packages = true
shamefully-hoist = true
shared-workspace-shrinkwrap = true
access = public
enable-pre-post-scripts = true

/turbo.json:

"db-generate": {
      "outputs": ["../../node_modules/.prisma/client"]
    },

/packages/db/prisma/schema.prisma

generator client {
    provider = "prisma-client-js"
    output ="../../../node_modules/.prisma/client"
}

/packages/db/.env

# Prisma
DATABASE_URL=<INSERT_DATABASE_URL>

Everything else matches current ‘create-t3-turbo-auth’, including a .env matching the example in /apps/nextjs. Can do a better job referencing later.