Generate Prisma Client when prerendering

[Tobbe]

After #5600 we now need access to the Prisma Client when pre-rendering. So even when just building for the web side we still need to generate the client if we're going to pre-render.

Just enabling the step for generating the client wasn't enough however. A new process needs to be kicked off for pre-rendering in order for it to pick up the new client.

Fixes #6088

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 30d9e54. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 14 targets

• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build

---

Sent with 💌 from NxCloud.

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	30d9e54
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/62ed1a919c97390008a0b1aa

[dac09]

So we always need access to Prisma or just when accessing db in routeHooks? Because this might point to a bigger issue (just in CLI imports, if I had to guess)

It might make more sense to move the prisma generate step to the prerender CLI so captures more cases? Otherwise it'll fail when you run yarn rw prerender and it won't make sense why.

[Tobbe]

So we always need access to Prisma or just when accessing db in routeHooks? Because this might point to a bigger issue (just in CLI imports, if I had to guess)

We instantiate the user's graphql handler, and it uses db. So we always need it.

import { createGraphQLHandler } from '@redwoodjs/graphql-server'

import directives from 'src/directives/**/*.{js,ts}'
import sdls from 'src/graphql/**/*.sdl.{js,ts}'
import { getCurrentUser } from 'src/lib/auth'
import { db } from 'src/lib/db'
import { logger } from 'src/lib/logger'
import services from 'src/services/**/*.{js,ts}'

export const handler = createGraphQLHandler({
  getCurrentUser,
  loggerConfig: { logger, options: {} },
  directives,
  sdls,
  services,
  onException: () => {
    // Disconnect from your database with an unhandled exception.
    db.$disconnect()
  },
})

[dac09]

@Tobbe I think I know why you need to run it as a separate process - just a thread to pull on.

Node will cache any imports (require statements) it sees in the run path - so when we first run the build command, it probably loads the graphql handler, and src/lib/db, before Prisma has had a chance to generate. This now gets cached.

So even though in later steps you generate the Prisma client, because the module was already loaded, it doesn't change.

It's worth making sure the imports of the graphql handler are done async (I haven't checked the code here though)

[Tobbe]

@dac09 Thanks for spending some time thinking about this.

I'll see what I can come up with between your idea of moving prisma client generation to the prerender cli, and those thoughts about node caching the imports

[Tobbe]

It's worth making sure the imports of the graphql handler are done async (I haven't checked the code here though)

It it async already, so that wasn't the easy fix we were hoping for 🙂

export async function getGqlHandler() {
  const gqlPath = path.join(getPaths().api.functions, 'graphql')

  const { handler } = await import(gqlPath)

  return async (operation: Record<string, unknown>) => {
    return await handler(buildApiEvent(operation), buildContext())
  }
}

[Tobbe]

It might make more sense to move the prisma generate step to the prerender CLI so captures more cases? Otherwise it'll fail when you run yarn rw prerender and it won't make sense why.

Trying to implement this I realized two things:

1. We already require our users to run yarn rw build web at least once before running prerender. We print an error message and quit if they haven't. So as long as prisma generate is part of build web we should still be good
2. Making prisma generation part of prerender makes it more difficult again to run them in separate processes. So running into that same error message I had from the start.

So either we keep it the way it is in this PR. Or we'll have to figure out how to generate the prisma client and run prerender in the same process

[dac09]

Lets get this in... but I still can't reproduce the following.

A new process needs to be kicked off for pre-rendering in order for it to pick up the new client.

[Tobbe]

@dac09 I figured out how to get it working without running in a separate process.
The key is this

// Purge Prisma Client from node's require cache, so that the newly
// generated client gets picked up by any script that uses it
Object.keys(require.cache).forEach((key) => {
  if (
    key.includes('/node_modules/@prisma/client/') ||
    key.includes('/node_modules/.prisma/client/')
  ) {
    delete require.cache[key]
  }
})

Which solution do you prefer? Deleting from the cache like that, or spinning up a separate process?

[dac09]

I think spinning up a separate process - just feels like there'll be less edgecases. But I'm glad we know what the cause is!

[dac09]

But I'm just going by gut feel - ideally we'd make sure prisma doesn't get imported - because that's likely to have memory benefits.

[Tobbe]

I think in most real-world scenarios prisma will be needed. Fetching ids from you DB is probably going to be the most commons scenario I think

[dac09]

It doesn’t need to be imported before generating the prisma client