Add support for Deno

[impowski]

Problem

Not yet supported in Deno

Suggested solution

Add support for Deno

It would be great to add support for Deno I'm not sure is it possible right now or in the future but seeing how Deno gaining momentum it will be a very near future.

[Miaourt]

Using wasm https://deno.land/manual/getting_started/webassembly for prisma engine might be interesting (see https://github.com/dyedgreen/deno-sqlite for example), aka if Deno run, Prisma run (afaik NodeJS 14 introduced experimental webassembly support)

Also to reply on the discussion thread linked up there, afaik no, you can't really use a npm package, there isn't even a notion of "package" or repo, see how Deno work on this field https://deno.land/manual/linking_to_external_code 😁

[softmarshmallow]

yeah prisma + deno just makes sense, and for prisma company itself, could take great market share on next-gen server development

[humbertoarizah]

#prismaday should announce deno support soon 😁

[timsuchanek]

Haha @HumbertoAriza thanks for tuning in!
Did you already use Deno in production?

[TsumiNa]

Is there any progress?

[pantharshit00]

@TsumiNa Not yet and I also suspect we won't be prioritizing this in the very near future as other important features like native types and stable migrate needs more attention.

This can climb in the priority if deno sees more adoption. Let us know if you are already using it in production.

[TsumiNa]

@pantharshit00 Thanks for letting me know this. I plan to use Deno as my next project's backend but found that I can't use it with Prisma. It frustrated me a little, but I still like to use Prisma migrate tools to manage my DBs. Please keep forwarding and polish Prisma better.

[ziimakc]

Was looking if prisma has support for deno and found this issue. Glad that prisma team has plans to support deno. @williamluke4 can you give estimation on how far in the future this can happen?

[williamluke4]

Hey @ziimakc, Currently this is just in the research stage and we are currently very busy with other features/bugs. So don't get your hopes up just yet.

The reason why this is not currently being actively pursued is that Deno is still very young and still has some growing pains.

If anyone would like to look into how we would achieve support for Deno, I'm willing to provide you with some support. 😄

Sorry I wish I could give you an ETA but I really can't

[khrj]

Did you already use Deno in production?

Let us know if you are already using it in production.

I'm already using Deno in production 👀

The DB drivers side for Deno is fairly empty right now, especially ORMs (There are some SQL drivers). This could be a great opportunity for Prisma to gain more popularity

[matthewmueller]

That's a good point @KhushrajRathod. It's a new ecosystem with lots of opportunity to grow. Supporting Deno is definitely on our list and something we'd like to start looking into soon.

It seems like the main thing is figuring out how our node dependencies in @prisma/client map to Deno. If anyone wants to help us start mapping, that could make this happen faster.

[khrj]

@matthewmueller I'd love to help! Which node dependencies does Prisma use? I don't see any in the package.json apart from devDependencies

[matthewmueller]

Very cool. Just did a quick check, definitely some work, but here's what I would probably do.

1. Create a sample Prisma project

1. npx prisma init
2. Write a basic schema.prisma
3. Sync with a database (sqlite is easiest)
4. npx prisma generate

2. Write a deno script

import { PrismaClient, Prisma } from './node_modules/@prisma/client/index.js'

const client = new PrismaClient()

async function main() {
  await client.$connect()
  const result = await client.user.create({
    data: {
      id: 1,
      name: "Alice",
    }
  })
  console.log(result)
}

main().catch(console.error).finally(() => {
  client.$disconnect()
})

3. Run deno index.ts and incrementally fix issues in ./node_modules/@prisma/client/index.js until it runs.

Some notable differences:

• CommonJS needs to be converted into ES Imports
• Paths with node_modules need to be resolved
• Node core libraries need to be swapped with deno libraries

There's probably more 😄

4. Share a diff of the changes to node_modules with us 🙌

[khrj]

Seems doable! I have some of sindre's promise-fun modules already ported over, and you seem to be using those

I'll work on this, lets see when we can get Prisma running on Deno :)

[khrj]

@matthewmueller Okay so after messing around a bit here's what I've gathered

• TypeScript will be a problem. Deno doesn't resolve .d.ts files by default, and needs explicit annotations to look at even a single .d.ts file -- see Support d.ts files denoland/deno#1432
• ESM is also a problem -- a lot of the generated code depends on exporting from within functions
• I don't think its practical to go through the generated code (70K+ lines) and manually change every import -- is there a better way to do this?

[matthewmueller]

Awesome, thanks @KhushrajRathod!

TypeScript will be a problem. Deno doesn't resolve .d.ts files by default, and needs explicit annotations to look at even a single .d.ts file -- see denoland/deno#1432

It seems like they could be manually mapped with /// <deno-types path="./bar.d.ts" />?

denoland/deno#2746 (comment)

ESM is also a problem -- a lot of the generated code depends on exporting from within functions

Hmm.. can you share an example in the generated code? I'm not sure why we're exporting dynamically.

I don't think its practical to go through the generated code (70K+ lines) and manually change every import -- is there a better way to do this?

Agreed. I think you could try running a codemod against the generated codebase. Perhaps babel with a plugin or this might work: https://github.com/eight04/cjs-es. "generated code depends on exporting from within functions" might pose a problem, but worth a try I think.

[janpio]

It indeed looks like Prisma (without Data Proxy) is now pretty "usable" in Deno @aarbi. But the corners are still pretty sharp:

We found some more issues with Prisma when using Deno and reported them:
denoland/deno#17265
denoland/deno#19544
denoland/deno#20099
denoland/deno#20098

Additionally, we are working with the Deno team again to fix smaller usability problems like the fact that deno run -A prisma generate might create a package.json file and install dependencies directly into node_modules. That currently makes Prisma feel very Deno untypical. We want to fix that.

We are also trying to figure out if there is a way around requiring the custom output property in your datasource in schema.prisma. If there is not, we might make a missing output a validation error instead.

[mendelbrot]

I am currently not able to connect to a local database with the Prisma client on Deno.

I get this error:

Error validating datasource `db`: the URL must start with the protocol `prisma:https://`

I commented in more detail here:
#20572 (comment)

[aarbi]

latest test with deno:

// main.ts

import { type PrismaClient } from "./src/generated/client/index.d.ts";
import { createRequire } from "node:module";
const require = createRequire(import.meta.url);
const Prisma = require("./src/generated/client/index.js");

try {
  const prisma: PrismaClient = new Prisma.PrismaClient();
  await prisma.user.create({
    data: {
      email: "[email protected]",
    },
  });

  console.log(await prisma.user.findMany());
} catch (e) {
  console.log(e);
}

// schema.prisma
generator client {
  provider        = "prisma-client-js"
  output          = "../src/generated/client"
  previewFeatures = ["deno"]
}

datasource db {
  provider = "sqlite"
  url      = "file:./database.sqlite"
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

deno version: 1.36 prisma version: 4.14.1

output:

deno run -A main.ts
[
  { id: 1, email: "[email protected]", name: null },
  { id: 2, email: "[email protected]", name: null },
  { id: 3, email: "[email protected]", name: null }
]

Edit: added types and it is working fine now

@mendelbrot tested with

• deno 1.38.1
• prisma 5.5.2

I am able to connect to local DB without the need to use the prisma edge proxy

[talkenson]

Hello to you all!
I'm tracking this issue for about a year, and today it's finally working okay.
Is there any tests/edge-cases in which prisma fails? (I'll try to find out anyway)

This is my patch (MacOS sed), for prisma 4.12.0 and 5.6.0

"prisma:patch:4": "sed -i -e 's/.\\/runtime\\/library/.\\/runtime\\/library.d.ts/g' src/generated/client/index.d.ts & sed -i -e 's/.\\/index/.\\/index.d.ts/g' src/generated/client/runtime/library.d.ts",
"prisma:patch:5": "sed -i -e 's/.\\/runtime\\/library/.\\/runtime\\/library.d.ts/g' src/generated/client/index.d.ts & sed -i -e 's/.\\/index/.\\/index.d.ts/g' src/generated/client/edge.d.ts",

Project

• Deno 1.38.2
• Prisma 5.6.0
• Postgres

As @aarbi mentioned, I have a file exporting prisma client

import { type PrismaClient } from '../client/index.d.ts'
import { createRequire } from 'node:module'
const require = createRequire(import.meta.url)
const Prisma = require('../client/index.js')


export const prisma: PrismaClient = new Prisma.PrismaClient()

For type imports I am using this in import map

"prisma": "./src/generated/prisma/index.ts",
"prisma/types": "./src/generated/client/index.d.ts",

Types are fine

No edge needed (4.12.0 and 5.6.0 tested)

As mentioned, you still need to add file extensions (mine patcher usage)

"prisma:generate": "npx prisma generate && deno task prisma:patch",
"prisma:migrate:dev": "npx prisma migrate dev && deno task prisma:patch",

Just FYI

generator client {
  provider        = "prisma-client-js"
  output          = "../src/generated/client"
  previewFeatures = ["deno"]
}

datasource db {
  provider = "postgresql"
  url      = env("POSTGRES_DB_CONNECTION_STRING")
}

POSTGRES_DB_CONNECTION_STRING=postgresql:https://postgres:changeme@localhost:5432/postgres?sslmode=disable

Also I'm using "nodeModulesDir": true in deno.json, and package.json with prisma

{
  "devDependencies": {
    "prettier": "^3.1.0",
    "prettier-plugin-prisma": "^5.0.0",
    "prisma": "^5.6.0"
  },
  "dependencies": {
    "@prisma/client": "^5.6.0"
  }
}

[juslin03]

thank @aarbi and @talkenson
It works like a shame

[ni-max]

deno 1.39.0 breaks it 👀

guess it is related to denoland/deno#21406

[chvogt16]

an alternative approach we have been testing lately (see the prisma runtime)

[janpio]

@ni-max: I can confirm that our tests passed with 1.38.5: https://github.com/prisma/ecosystem-tests/actions/runs/7199864192/job/19612700300
And time out with 1.39.0 during prisma generate: https://github.com/prisma/ecosystem-tests/actions/runs/7210709794/job/19644656032

Update: Deno is already looking into it.
Update 2: Issue on Deno side: denoland/deno#21630

[ni-max]

I can confirm that denoland/deno@d13e45f broke it
And as of this moment the latest commit that works is the one before it: denoland/deno@a272bc1

to use it:

deno upgrade --canary --version=a272bc1bd0793b2f522e4e611963231dc344531f

Also there is no need to patch the prisma-client since --unstable-sloppy-imports is available in this version.

[bartlomieju]

I'm in the process of releasing Deno v1.39.1 which fixes the above problem.

[DimitryDushkin]

By the state of Feb 2024 it's still not working. The main reason that correct ESM exports are only generated for generated/deno/edge.ts, but this code only works if you use Prisma Accelerate cloud hosting for databases. Since "edge" in this case assumes "serverless deploy with remote DB on Accelerate". Normal generated prisma client is using CommonJS exports incompatible with Deno.

Solution mentioned above with createRequire doesn't work with modern versions of deno's std library since they removed it 🤷‍♂️ I read somewhere that motivation is "npm: should be enough" which brakes perfectly by Prisma's code generation case.

So I guess the only proper fix will be Prisma's updated code generation for non-edge variant.

[barthuijgen]

It's been so long, I just started using drizzle orm instead. And honesty, it's better anyway.

[DimitryDushkin]

It's been so long, I just started using drizzle orm instead. And honesty, it's better anyway.

Oh that’s for a pointer! Seems like a solid alternative.

[aarbi]

I have started to get "top level promise is never resolved" error here.
I tried to setup the package using npm, then run it using the --unstable-byonm flag when running.

[janpio]

Currently Prisma is blocked by problems in Deno's Node-API support: denoland/deno#24010
This issues has just been resolved by Deno, and we are now double checking if this indeed works and resolves the problems currently present. I will post here when we know more.

[janpio]

Good news, that canary version of Deno fixes all known problems. Here is a script that shows the remaining hoops to jump through to get it imported properly: https://github.com/prisma/ecosystem-tests/pull/5077/files#diff-6c4a961c8d767d8f7d2fe59e058a337a7e3801f1d9990829aa62924fa24dcb3e

I will post again when that canary version has been released so you can all test it yourself 🥳

[aarbi]

I can confirm this is working using the code I posted in a previous comment.
To test this right now, upgrade deno to the latest canary version using

deno upgrade --canary

[janpio]

Deno v1.44.2 is out, and Prisma works pretty well with it!

Two limitations we are aware of for now:

1. You need to use a custom output path

   generator client {
     provider   = "prisma-client-js"
     output     = "../generated/client"
   }

2. You need to do a slightly weird import to get Prisma Client into your Deno app:

   import { type PrismaClient } from '../generated/client/index.d.ts'
   import { createRequire } from 'node:module'
   const require = createRequire(import.meta.url)
   const Prisma = require('../generated/client/index.js')
   
   const prisma: PrismaClient = new Prisma.PrismaClient()
   

Please give us feedback if this also works for you, if you run into any trouble or how things go!

[chrisabrams]

Deno v1.44.2 is out, and Prisma works pretty well with it!

Two limitations we are aware of for now:

1. You need to use a custom output path

   generator client {
     provider   = "prisma-client-js"
     output     = "../generated/client"
   }

2. You need to do a slightly weird import to get Prisma Client into your Deno app:

   import { type PrismaClient } from '../generated/client/index.d.ts'
   import { createRequire } from 'node:module'
   const require = createRequire(import.meta.url)
   const Prisma = require('../generated/client/index.js')
   
   const prisma: PrismaClient = new Prisma.PrismaClient()
   

Please give us feedback if this also works for you, if you run into any trouble or how things go!

@janpio I have been doing this for over a year now with Deno and it has worked fine. What changed in 1.44.2 to improve support for this?

[janpio]

It had stopped working with Deno 1.39.x for the default case of our library Query Engine (so I assume you might still be on an older version where it used to work?), and for our engineType=binary it hadn't worked at all until 1.43.0. Now with 1.44.2 it works for both and we have the tests to prove it: prisma/ecosystem-tests#5082

[kylesloper]

Currently running into issues with this. @janpio is this working for Netlify Edge functions too?

[mmeylan]

Struggling to get a new deno project (1.44.2) working with prisma and sqlite. Getting Error validating datasource db: the URL must start with the protocol prisma:https:// even without using the edge generated files.

[fuji44]

Thank you, @janpio The method you suggested worked.

However, there were some problems with type references (for example, the return type of findUnique was any), and Prisma's strengths were lost. This problem could be solved by making a small modification to the generated code.

// generated/client/index.d.ts

-import * as runtime from './runtime/library.js';
+import * as runtime from "./runtime/library.d.ts";

The code generated by previewFeatures = ["deno"] imports library.d.ts, so it may be a generator issue.