ES5 support on 7?

[gcb]

Hi. We are using ES5 target on a nextjs project to work around some Safari bugs (and nextjs forces you to use the same target for backend and frontend)

But we also want to migrate that project from prisma6+binaryTargets to prisma7+adapter-pg

Is it wise to migrate to prisma7+adapter-pg (which I assume is all JS code?) and still push the ES5 target?

backend code runs on latest nodejs, that only impacts the generated code from our .ts build step. So i am assume it should be safe, right? Or does prisma generate step is affected somehow by our tsconfig?

[sandeep-2607]

Short answer: the ES5 target shouldn't matter for Prisma 7 at runtime, but it can trip the type-check, and it probably isn't the setting that fixes your Safari issue anyway.

Runtime. Prisma Client + @prisma/adapter-pg only ever runs on the server, so Safari never executes it. The v7 upgrade guide lists the minimums as Node 20.19.0 and TypeScript 5.4.0. As long as your server meets those, the browser target is irrelevant to Prisma.

Where ES5 can bite: type-checking. The v7 prisma-client generator emits TypeScript files (generatedFileExtension defaults to ts), so they're type-checked under your tsconfig, and next build fails on TS errors. With "target": "ES5", TypeScript rejects some modern syntax even when it's only type-checking (e.g. TS18028: Private identifiers are only available when targeting ECMAScript 2015 and higher). I haven't checked whether the generated client actually uses any of that. The quick test is to run prisma generate and then:

npx tsc --noEmit

If it's clean, you're fine. If it isn't, see the last section.

Does prisma generate read your tsconfig? The generators docs say fields not set explicitly are "inferred from your environment and tsconfig.json". That covers things like moduleFormat and importFileExtension, not the ES target. If you want it deterministic, set them in the generator block.

For the Safari bugs. Next.js compiles your code with SWC, and browser support is controlled by Browserslist in package.json. The default is ["chrome 111", "edge 111", "firefox 111", "safari 16.4"] (supported browsers). I couldn't find anything in the Next.js docs saying tsconfig's target changes the compiled output, so I'd set the Safari versions you need in browserslist (plus polyfills as that page describes) and move tsconfig back to a modern target like ES2017+. That would also remove the type-check risk above.

[gcb]

Thank you!

Runtime. Prisma Client + @prisma/adapter-pg only ever runs on the server, so Safari never executes it. The v7 upgrade guide lists the minimums as Node 20.19.0 and TypeScript 5.4.0. As long as your server meets those, the browser target is irrelevant to Prisma.

this was my main fear. That something in here would be used when compiling js from some generated ts. But if everything lives in generated path, indeed it is all good.

And thanks for the note on Browserslist too. I'm trying to compile to ES5 to ease the transpile step on the nextjs build. Since i'm having to go with the default (pretty old) versions because of the safari issues, I noticed that es5->next build creates less polyfills. (based on file sizes, didn't investigate content)

[SudoKMaar]

I ran the check that was left open above, since "does the generated client survive target: ES5" is the whole question.

Setup: prisma@7.10.1, @prisma/client@7.10.1, @prisma/adapter-pg@7.10.1, TypeScript 5.9.3, prisma-client generator (emits .ts into generated/prisma), one model with a BigInt and a String[] column, and a Next.js-style tsconfig: "target": "ES5", "lib": ["dom", "dom.iterable", "esnext"], strict, isolatedModules, moduleResolution: bundler. Then tsc --noEmit on my code plus the generated files.

• target: ES5, skipLibCheck: true (the Next.js default): clean. Same result with ES2017.
• target: ES5, skipLibCheck: false: fails, 4 errors, all TS18028: Private identifiers are only available when targeting ECMAScript 2015 and higher, all in node_modules/@prisma/client-runtime-utils/dist/index.d.ts (the #private members on AnyNullClass, DbNullClass, JsonNullClass, ObjectEnumValue). Nothing in the generated client itself trips ES5; the 116 KB of generated .ts has no private identifiers and no bigint literals.

So: the generated code is fine at ES5. The only thing that bites is a .d.ts inside Prisma's runtime package, and only if you have turned skipLibCheck off. Keep it on (or move to ES2015+) and prisma generate + type-check will pass.

Two things your tsconfig target does not affect, which is why it is otherwise harmless here:

• The runtime (@prisma/client/runtime/*.js, @prisma/adapter-pg) is prebuilt JS in node_modules; tsc never compiles it, so it runs as modern code on Node regardless of your target. @prisma/client 7.10.1 declares "node": "^20.19 || ^22.12 || >=24.0".
• prisma generate does not read target from tsconfig. Per the generator docs it only infers moduleFormat and importFileExtension from the environment, and you can pin those in the generator block.

On the Safari side, +1 to the previous reply: Next.js compiles browser output from Browserslist, not from tsconfig target (default is ["chrome 111", "edge 111", "firefox 111", "safari 16.4"], see https://nextjs.org/docs/architecture/supported-browsers). If the ES5 target is only there for Safari, a browserslist entry in package.json is the lever, and you can let target go back to ES2017 or later, which also removes the skipLibCheck edge case above.