prisma-client provider and vanilla JS support?

[M1CK431]

Bug description

As stated on the official Prisma website, both Javascript (aka "vanilla") and TypeScript are supported languages.

However, while trying prisma-client provider with generatedFileExtension = "js", generated files are still using TypeScript (despite .js extension) and so can't be used in vanilla JS files.

Severity

🔹 Minor: Unexpected behavior, but does not block development

Reproduction

Not relevant

Expected vs. Actual Behavior

Expected: generatedFileExtension = "js" should generate vanilla JS files
Actual: TypeScript files with .js generated

Frequency

Consistently reproducible

Does this occur in development or production?

Both development and production

Is this a regression?

No since related to an "Early Access" feature.

Workaround

Remain on prisma-client-js provider

Prisma Schema & Queries

Not relevant.

Prisma Config

Not relevant

Logs & Debug Info

Not relevant

Environment & Setup

• OS: Archlinux
• Database: SQLite
• Node.js version: v24.2.0

Prisma Version

From package.json:

{
  "prisma": "^6.10.1"
  "@prisma/adapter-better-sqlite3": "^6.10.1",
  "@prisma/client": "^6.10.1",
}

[M1CK431]

Answer to myself: node --experimental-transform-types index.js
And in index.js we can now import { PrismaClient } from './generated/prisma/client.ts';
Obviously this is just a workaround but still might be useful for others.

NB: --experimental-transform-types is available only from node v22.7+. Use tsx as an alternative for previous version.

[jkomyno]

Hey @M1CK431, the new prisma-client generator emits TypeScript files only, and it does so by design.
The generatedFileExtension configuration attribute doesn't support js, but it supports ts, mts, cts.
See docs.

As stated on the official Prisma website, both Javascript (aka "vanilla") and TypeScript are supported languages.

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

---

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.

I'd always recommend bundling your app in production, but if you want to run Prisma locally without compiling TypeScript to JavaScript, and without using node --experimental-transform-types, I'd recommend using bun or deno, depending on your use case and how many Node.js-centric features your app relies on.

[M1CK431]

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 🤗

[carnoxen]

#27503

When GA is reached, we plan to deprecate the older prisma-client-js generator.

prisma-client-js will be deprecated because of prisma-client.

[M1CK431]

So,

both Javascript (aka "vanilla") and TypeScript are supported languages.

...will ends with Prisma v6 😭

[xxsuperdreamxx]

@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

[M1CK431]

Thanks, I'm using --experimental-transform-types (stability 1.2) without any issue too. Still, your workaround looks good, especially for people which can't use tsx.

Anyway that discussion is about an official statement from Prisma.

[xxsuperdreamxx]

Thanks, I'm using --experimental-transform-types (stability 1.2) without any issue too. Still, your workaround looks good, especially for people which can't use tsx.

Anyway that discussion is about an official statement from Prisma.

The issue with using --experimental-transform-types is because of stability 1.2, we have seen in the past that breaking changes can occur even in that stage

[M1CK431]

You're right; it's unlikely but might happen. tsx could be considered a more stable alternative in this case, albeit at the cost of an extra dependency.

[xxsuperdreamxx]

@M1CK431 I am fine with it since tsx is actively maintained, I was going to be salty about it, if it was one of those with the deprecated dependencies or a useless package like lodash

[xxsuperdreamxx]

Also, tsc not tsx, we are only compiling them to js, we are not using tsx to execute the typescript together with js (not to confuse people when they are reading that solution)

[xxsuperdreamxx]

Update for people who will see this Node.js now officially supports TypeScript as of v25.2.0, so you do not need our implementation; you can just directly run the ts files from js files now. I have tested it and no complaints

[M1CK431]

@xxsuperdreamxx Not yet since Prisma client may generate TS enum (depending of your schema) and so --experimental-transform-types flag is still needed (and not marked as stable yet). For reference: nodejs/node#60600 (the Notice after the screenshot in the description: "transform-types will stay experimental for now")

[NTag]

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.

[xxsuperdreamxx]

@jkomyno I appreciate the clarification, but there is a significant difference between "still works" and "officially supported." By deprecating prisma-client-js without providing a vanilla JS equivalent in the new prisma-client generator, Prisma is effectively telling JS users their current workflow has a fast-approaching expiration date.

For teams with large, production vanilla JS codebases, “it still works for now” isn’t a viable long-term migration strategy, as migrating everything to TypeScript (or changing runtimes) isn’t realistic.

What is the planned path forward for vanilla JavaScript support once the prisma-client-js generator is removed? Is the long-term vision TypeScript-only, or are there plans to add JS output to the new generator?

@NTag’s core point remains: non-TypeScript users need clearer, upfront guidance in the docs and migration guides to avoid uncertainty about continued support, especially for those projects who have been long-term users of Prisma where it is already a core component of the codebase.

node js now supports native running of TS. So you can use it without vanilla JS

[M1CK431]

Not yet: #27596 (comment)

[xxsuperdreamxx]

Not yet: #27596 (comment)

Not true, it is officially part of the Stable release for almost 1 month now

https://nodejs.org/api/typescript.html

[xxsuperdreamxx]

In fact I am also using it for a while now without a single problem

[M1CK431]

Not yet: #27596 (comment)

Not true, it is officially part of the Stable release for almost 1 month now

https://nodejs.org/api/typescript.html

Please read my linked comment carefully. Also, the link you provide clearly state:

There are two ways to enable runtime TypeScript support in Node.js:
For full support of all of TypeScript's syntax and features, including using any version of TypeScript, use a third-party package.
For lightweight support, you can use the built-in support for type stripping.

Prisma needs "Full support" if enum is used in the schema so NodeJS built in TS support is not yet enough, unless using --experimental-transform-types flag. Again, it's clearly explained in the link you provide in "Type stripping" section.

[querta]

It doesn't work with vanilla js natively but you still could build your project. If you don't know how to work with typescript here's a small instruction:

1. Follow the official documentation to set up your schema and database
2. Use the .ts extension in your imports within your JS files:
   import { PrismaClient } from '../generated/prisma/client.ts';
3. Install tsx and tsup (or other builder) as dev dependencies to handle the types:
   pnpm add -D tsx tsup
4. Use tsx for development and tsup for production to compile your project into clean JavaScript.

package.json:

  "scripts": {
    "dev": "tsx watch --clear-screen=false app.js",
    "build": "tsup index.js --format esm --clean --minify",
    "start": "node dist/index.js",
    "serve": "pnpm build && pnpm start"
  },