Hi @jkomyno , thanks for your reply.

The statement is true for Prisma 6, as prisma-client-js still exists, regardless of the design choices of the new prisma-client generator :)

Does it means prisma-client-js will be supported forever? Or at least in Prisma 7 (without "deprecation")?

The idea is that the generated Prisma Client files become part of your own codebase, rather than being hidden within node_modules. This allows you to bundle and transpile them however you see fit, which in turn avoids a plethora of failing edge cases on modern frameworks.

From official documentation, regardless of where the client files are generated, they will never really become part of my own codebase since they have to be excluded from Git. So no real difference compared to being generated in node_modules (except the import path... 🤭).

I'd always recommend bundling your app in production

Why? What's the benefit compared to --experimental-transform-types or tsx?

A last side note, despite I'm not so attached to terminology in most cases, Typescript can't be "compiled" to Javascript. The correct term is "transpilation" (Yes, I know you know it because you use that term too earlier in your reply). IMHO it' very important for people to understand that Javascript stands by itself. TypeScript might be useful is some cases as a DX enhancement, but at runtime, it doesn't even exist.

Anyway, thank you for your insights. I appreciate your clarification.
Looking forward to your thoughts 🤗

@M1CK431 I have a solution that is a bit weird, but it does an amazing job

required npm packages:
tsc

tsconfig.prisma.json

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "Node",
    "outDir": "./generated/prisma",
    "rootDir": "./generated/prisma-ts",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "strict": false,
    "declaration": true,
    "resolveJsonModule": true,
  },
  "include": ["./generated/prisma-ts"]
}

Prisma Schema settings:

generator client {
  provider             = "prisma-client"
  output               = "../generated/prisma-ts"
  importFileExtension  = "js" // Essential since your tsc conversion cannot change imports
}

package json script

"generateClient": "npx prisma generate && tsc --project tsconfig.prisma.json",

example import

import { PrismaClient } from '../generated/prisma/client.js'
const prisma = new PrismaClient()

This works pretty fine IMO, everything worked without any issues, I did testing with my current project and the supertest passed, and I have like 100 custom things on top of Prisma, including custom extensions, and nothing said "I do not like it"

It is a better alternative to --experimental-transform-types since, at the end of the day it is experimental

After Prisma CLI complained for a few weeks that I should upgrade to v7, I finally decided to tackle this migration. I open the guide, follow the instructions, and oh at some point I need to import ts files but my project is in JavaScript. That doesn't work (I just use bare NodeJS on the backend).

• Why isn't the first sentence of this guide "If you don't use TypeScript, you need to abandon Prisma, or stay under v6, or migrate to TypeScript"?
  Even worse, what is the guide saying things like "If you are using TypeScript" because now TypeScript is required?
• if TypeScript isn't required, as some messages in this discussion tend to say, then details about the possible solutions should be added to the migration guide. Prisma supported JavaScript until now, so they are people who just use NodeJS and no other tooling: the migration should accompany them.

Three things:

• NodeJS is for JavaScript. They are projects which don't use TypeScript. It's a great tool, it's awesome to have typed libraries (like Prisma) to have nice autocomplete in VSCode, but a TypeScript codebase requires a more complex toolchain, make node_modules heavier… You shouldn't assume that everyone uses TypeScript. There are also old projects which aren't been migrated to TypeScript;
• don't justify that it's legit that the website says Prisma supports TypeScript & JavaScript when the JavaScript support is a deprecated library. That's misleading and dishonest;
• don't present Bun or Deno as solutions. For some cases maybe there are, but don't assume everyone can use them. Or then say that Prisma is a library for Bun or Deno and say NodeJS isn't supported. Bun or Deno are awesome projects, but not every library are yet compatible with them, making them unusable in production for many people.

Some people are using Prisma in production for years with a huge JavaScript codebase. You can't ask those people to migrate their 50,000 files to TypeScript, or to switch to Bun. That's not serious.

TL;DR:

• when you say you offer a NodeJS/NPM library, don't assume anything about the stack of the users, and don't push any additional tool, or change of tool;
• if Prisma 7 is still compatible with JavaScript projects, explain in the migration how it should be done 🙏 . With realistic solutions which involve not switching to Bun, nor using experimental flags;
• And if Prisma is turning into a TypeScript-only library, make it clear, say it on the first page of the website, don't lie, announce it on the blog.