Prisma Edge Client + CF Worker `process not defined`

Bug description

Getting process not found error when deploying the prisma Edge client to Cloudflare pages. Isn the Edge client supposed to prevent this error from happening? I am only using the client in SvelteKit Endpoints https://kit.svelte.dev/docs/routing#endpoints

NOTE: I am using dot-env package to run the local dev script in package.json as prisma cannot find my .env DATABASE_URL var without this command (Maybe this is related to the issue?)

Err Log:

{ text: 'Uncaught ReferenceError: process is not defined\n' + ' at line 8755 in node_modules/.prisma/client/edge.js\n' + ' at line 16 in __require2\n' + ' at line 8768 in node_modules/@prisma/client/edge.js\n' + ' at line 16 in __require2\n' + ' at line 8774\n' + ' at line 8789\n' + ' [code: 10021]' }

How to reproduce

1. Set up Prisma data-proxy in SvelteKit following this instructions https://www.prisma.io/docs/concepts/data-platform/data-proxy
2. Deploy to CF pages and see that it builds successfully, but when visiting a page it will have the process not found error

You should be using the Edge Client and --data-proxy option with npx prisma generate. And your database_url should start wit prisma://

Expected behavior

I’m not executing code that is meant for the server on the client so I dont understand why this error is happening

Prisma information

I have a demo of the issue here https://github.com/vidiabtc/sveltekit-test

Environment & setup

• OS: MacOS–>
• Database: MySQL
• Node.js version: v16.7.0

Prisma Version

		"prisma": "^3.15.1",
		"@prisma/client": "^3.15.1",

[aqrln]

This issue is now fixed and the fix will be released in Prisma 4.2.0 on Tuesday, Aug 9.

Prisma won’t crash trying to access process.env when using the new Module Workers format of Cloudflare Workers (including the SvelteKit use case). You shouldn’t need the workaround with node_compat shared earlier in this thread anymore.

Please note that with Module Workers there are no global bindings for secrets and environment variables that Prisma could use (see this comment). Instead, the env object is passed as a parameter to the fetch handler:

interface Env {
  DATABASE_URL: string
}

export default {
  async fetch(request: Request, env: Env /* <-- here it is! */, ctx: ExecutionContext): Promise<Response> {
    // ...
  }
}

See Cloudlfare docs for more details: https://developers.cloudflare.com/workers/learning/migrating-to-module-workers/

The implications are:

1. Prisma Client must be created inside the handler and not on the module level. This is a Cloudflare limitation which we cannot work around. You can cache the created Prisma Client instance using a module-level variable though, and only create it inside the handler once if it’s null.

2. The datasource URL has to be passed like this:

   const prisma = new PrismaClient({
     datasources: {
       db: {
         url: env.DATABASE_URL
       }
     }
   })
   

   We may come up with an API to make it less verbose in the future, but for now overriding the datasource URL with the value from the env parameter of the fetch handler is the official guideline when using Prisma with Module Workers. We will work on the guide and add it to the documentation.

Note that this doesn’t apply to the old Service Workers format — everything should work as usual there.

Finally, and this is not strictly related to this issue, we added an error to assist you debugging a missing environment variable. Instead of not very helpful InvalidDatasourceError: Could not parse URL of the datasource you will get more explicit InvalidDatasourceError: Datasource "db" references an environment variable "DATABASE_URL" that is not set.

In the context of Cloudflare Module Workers, when overriding the datasource URL manually, you are more likely to see this error if you forgot to add a secret using wrangler: Error: Invalid value undefined for datasource "db" provided to PrismaClient constructor. This is not a new error, we have supported it before.

However, the new error will hopefully be helpful when using Service Workers, when not using Cloudflare Workers at all, or if you didn’t override the datasource with Module Workers.

[drewdecarme]

If you’re using Wrangler@2 and you’re using a .toml file. you can add this property to get around it. Wrangler spits a nasty warning out at you, but to this point I haven’t had an issue in production.

# Add polyfills for node builtin modules and globals
node_compat = true

Here’s the docs for it: https://developers.cloudflare.com/workers/wrangler/configuration/. Just scroll down until you see node_compat

Just waiting until Prisma fixes this issue.