This is an investigation log written with the assumption that it will be translated in order to report it as an issue on GitHub.
Basically, I am responsible for trying to use prisma's experimental query-compiler, but the interfaces of opennext, prisma, and @auth/adapter-prisma all did not mesh, and the only solution to avoid the problem was to directly patch @auth/adapter-prisma.
What happened with @auth/adapter-prisma is a typical example, and there are two issues: how prisma itself will design its interface in the future, and how opennext should handle cjs.
An error occurred while validating opennext + next-auth + prisma + prisma-adatper.
import NextAuth, { NextAuthConfig, User } from "next-auth";
import Github from "next-auth/providers/github";
import Credentials from "next-auth/providers/credentials";
import { prisma } from "@/db";
import { PrismaAdapter } from "@auth/adapter-prisma";
export const authConfig: NextAuthConfig = {
adapter: PrismaAdapter(prisma),
providers: [
Github({}),
],
secret: process.env.AUTH_SECRET!,
};
export const { handlers, auth, signIn, signOut } = NextAuth(authConfig);When you run a preview build in the opennext environment, an error occurs in the following runtime code.
bP=rh({".open-next/server-functions/default/node_modules/.pnpm/@[email protected][email protected][email protected][email protected]/node_modules/@prisma/client/runtime/library.mjs"(){D0=dS.fileURLToPath(import.meta.url),Jl=BS.dirname(D0),tf=Ph(import.meta.url),
This is simply an error that calls fileURLToPath(undefined). The wrangler ultimately makes import.meta.url undefined.
The workaround is simple, given the complexity of the problem.@auth/adapter-prisma The code is relatively simple, so you just need to rewrite and patch the TS code directly.
// Avoid this
// import { PrismaClientKnownRequestError } from "@prisma/client/runtime/library"
/// check only error code
// If token already used/deleted, just return null
// https://www.prisma.io/docs/reference/api-reference/error-reference#p2025
if (
// error instanceof PrismaClientKnownRequestError &&
(error as any).code === "P2025"
)
return null;
}prisma generate --no-engine(query-compiler) generates code undersrc/generated/prisma- At this time, a file equivalent to
@prisma/client/runtime/library.mjsis not generated @auth/prisma-adaptertries to reference an instance withimport { PrismaClientKnownRequestError } from "@prisma/client/runtime/library"- At this time,
fileURLToPath(import.meta.url)in@prisma/client/runtime/library.mjsis evaluated - opennext compiles server-side code to cjs
import.meta.urlin the cjs environment is not statically deployed by the bundler (webpack/esbuild)import.meta.urlbecomes undefined in the cloudflare workerd environment- Prisma issue
@prisma/client/runtime/library.mjsis not generated- Even if it is generated, porting existing code will not work in the workerd environment
- @auth/prisma-adapter issue
output = "../src/generated/prisma"pattern is not taken into consideration- Opennext issue
- Should
import.meta.urlin cjs be statically expanded?
prisma generate --no-engine(query-copmiler) issue@prisma/client/runtime/library.mjsis not generated- Even if this is generated, porting existing code will not work in a workerd environment
@auth/prisma-adapterissueoutput = "../src/generated/prisma"pattern is not taken into consideration- Opennext issue
- Should
import.meta.urlin cjs be statically expanded?
I'm very tired.
Simply. To just work around my problem, I would simply build opennext with only libraries that don't reference @prisma/client/runtime/library.
But I feel like I'm getting a glimpse of potential issues with each library.