Bun doesn't run prisma generate or prisma migrate inside docker containers or WSL

[sum117]

What version of Bun is running?

1.0.1+31aec4ebe325982fc0ef27498984b0ad9969162b

What platform is your computer?

Microsoft Windows NT 10.0.22621.0 x64

What steps can reproduce the bug?

Docker:

FROM oven/bun AS builder

WORKDIR /tmp/app

COPY package.json .
COPY bun.lockb .

RUN bun install

COPY src ./src
COPY tsconfig.json .

# This would be the optimal solution but it doesn't work, so I'm gonna use a hack here until I figure out how to fix it
#   RUN bunx prisma:generate
#   COPY prisma/schema.prisma ./prisma/schema.prisma
COPY node_modules/.prisma ./node_modules/.prisma

RUN bun run build

FROM oven/bun AS runner

ARG DEFAULT_DATABASE_URL= "file:./deploy.db"
ENV DATABASE_URL=$DEFAULT_DATABASE_URL

WORKDIR /app

COPY --from=builder /tmp/app/package.json /app/package.json
COPY --from=builder /tmp/app/bun.lockb /app/bun.lockb
RUN bun install -p

# Refer to the comment above
#   COPY --from=builder /tmp/app/prisma/schema.prisma ./prisma/schema.prisma
#   RUN bun run prisma:generate
COPY --from=builder /tmp/app/node_modules/.prisma /app/node_modules/.prisma

#   These commands aren't working either. The prisma:migrate has to be done in the external machine
#   RUN bun add prisma
#   RUN bun run prisma:migrate

COPY --from=builder /tmp/app/build /app/build

CMD ["bun", "start"]

WSL:

Install WSL normally...

wsl --install

Make bun installation inside Ubuntu.

Try to follow this exact guide: https://bun.sh/guides/ecosystem/prisma

What is the expected behavior?

Prisma installs normally

What do you see instead?

This, download never finishes:

root@7fa00e64baa1:/app# bun run prisma:deploy
$ bunx prisma migrate deploy
Downloading Prisma engines for Node-API for debian-openssl-1.1.x [===                 ] 15%root@7fa00e64baa1:/app#

Additional information

No response

[sum117]

Issue with Prisma CLI commands seems to be fixed in v1.0.2. Run bun upgrade and try again. Reopen this issue if it doesn't work for you with additional OS details.

[DeepDoge]

I use devcontainer with the docker image mcr.microsoft.com/devcontainers/base:jammy.
I have the same problem with bun version 1.0.2.

When i only run:

bunx prisma

It runs gives me the --help response. But nothing else works:

• bunx prisma init
• bunx prisma migrate
• bunx prisma generate
• etc...

Sometimes randomly, it says this:

Downloading Prisma engines for Node-API for debian-openssl-3.0.x [================    ] 81%

[rileychh]

1.0.2 with Docker also has non-working prisma generate.

OS Info:
oven/bun:1.0.2
Docker version 24.0.5, build ced0996600
Arch Linux 6.5.3-zen1-1-zen

[veloxy]

Same issue here, in the oven/bun docker container:

root@69248dd04828:/app# bun -v 
1.0.2
root@69248dd04828:/app# bunx prisma migrate deploy   
> Downloading Prisma engines for Node-API for debian-openssl-1.1.x [=========           ] 47%root@69248dd04828:/app# 

Stops are 47%, no errors or anything.

I'm also running docker on wsl, but I don't think that matters?

[sum117]

Thanks for all the feedback guys. I have reopened this issue because of it. I'm sorry this is still a problem for your use case and I ask you pardon for my oversight.

The core team will hopefully come back to us, I'm sure of it!

[kylemclaren]

Same issue here, bunx prisma generate completes but client is not generated

[lentg]

+1

[sorenhansendk]

First you need to include nodejs in your Docker image. That is required for Prisma to work with Bun:

# Dockerfile
COPY --from=node:18 /usr/local/bin/node /usr/local/bin/node

After that you need to trust the Prisma client package, so it can execute postinstall scripts:

# package.json
"trustedDependencies": [
  "@prisma/client"
],

With this, I'm able to run bun install and it generates my schema without any problems.

I can also run bunx prisma generate without any problems. Here is my full Dockerfile:

FROM oven/bun:1.0.2
WORKDIR /opt/app

COPY --from=node:18 /usr/local/bin/node /usr/local/bin/node
COPY ./packages ./packages
COPY ./package.json ./
COPY ./bun.lockb ./

# Install packages
RUN bun install

# Run generation
RUN bunx prisma generate

It still dosen't work with the ARM image. I think Prisma missing a ARM build of the Debian engine.

[veloxy]

First you need to include nodejs in your Docker image. That is required for Prisma to work with Bun:

Kinda defeats the purpose of using Bun as it is a Node.js replacement 😕

It would also make the image larger, I don't want to ship Node.js and Bun to run migrations.

[sorenhansendk]

Kinda defeats the purpose of using Bun as it is a Node.js replacement 😕

I agree. This is not a super optimal solution, but for now, I think it's more clean than copying node_modules around.

It would also make the image larger, I don't want to ship Node.js and Bun to run migrations.

You can use a multi-stage build, if you don't want to include Node.js in your final image, or delete it after prisma commandas has ran. Something like this: RUN rm -rf /usr/local/bin/node

[wedelgaard]

I'm experiencing this issue as well. I tried a different approach which is not optimal as well, but dont seem to work. I ran bun run prisma generate locally and copy the generated files to a new folder prisma-client/client. Then when I build my Docker Image i copy that folder into the /node_modules/@prisma/client folder.

This is what my Dockerfile looks like:

FROM oven/bun:1.0.2
ENV NODE_ENV=production
WORKDIR /usr/src/app
COPY package.json bun.lockb ./
RUN bun install
COPY prisma-client/client /node_modules/@prisma/client
COPY . .
RUN rm -rf prisma-client
EXPOSE 3000
CMD [ "bun", "run", "start" ]

Unfortunately I'm still seing the same error:

2023-09-22 11:58:58 $ bun run src/index.ts
2023-09-22 11:58:58 
2023-09-22 11:58:58 
2023-09-22 11:58:58 error: Cannot find module ".prisma/client/index" from "/usr/src/app/node_modules/@prisma/client/index.js"
2023-09-22 11:58:58 error: script "start" exited with code 1 (SIGHUP)

[wedelgaard]

By following @sorenhansendk example I was able to get it working, but I had to define a custom output path for the prisma generated files:

https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/generating-prisma-client#using-a-custom-output-path

[veloxy]

You can use a multi-stage build, if you don't want to include Node.js in your final image, or delete it after prisma commandas has ran. Something like this: RUN rm -rf /usr/local/bin/node

True, but for my usecase I need to run migrations when the container starts, which is only possible with Prisma using npx (afaik). So it's unfortunately not a solution for me, I think? Or can you run bunx without node after bun install with node? I'll try it later. Thank you for providing a work-around at least!

[sorenhansendk]

So it's unfortunately not a solution for me, I think? Or can you run bunx without node after bun install with node?

I have not tested migrations without Node.js included. I think you will run into problems - but let us please know the result 👍

[sacummings91]

Just to add on to this. The current state of bun install using Bun v1.0.3 with prisma for us is this.

Locally bun install does not execute the postinstall script to generate the client in node_modules/.prisma/. But if you run bun run prisma generate it works as expected and generates the client.

In our Gitlab CI/CD runners using docker, bun install also does not execute the postinstall script. But here even running bun run prisma generate does nothing as well. We can confirm this by running tsc afterwards and it fails every place we import the Prisma Client or the types it generates.

[antn9x]

This still not working with bun 1.0.3
My docker file

FROM oven/bun:1.0.3 as base
WORKDIR /app/
COPY package.json bun.lockb ./
COPY ./src ./src
COPY ./prisma ./prisma
RUN bun install --production
RUN bunx prisma generate
CMD bun run deploy-one

[DeepDoge]

Alright, I was able to run it by also having node installed in the container.
I don't know but, this might be a prisma problem, looking specifically for node, not sure.

Here's my devcontainer.json:

{
    "name": "Bun & Node.js & TypeScript",
    "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bullseye",
    "features": {
        "ghcr.io/shyim/devcontainers-features/bun:0": {}
    },
    "postCreateCommand": "bun i",
}

[mausworks]

Ran into the same issue today. Adding with some speculations on my side:

It's super weird, bun prisma generate prints nothing to the console on build/start (on railway.app), but works perfectly locally.

I guess bun (at some point) runs Node (instead of itself), but then fails silently if Node is not installed. Locally, this works, since I have both installed.

There is provably something in Prisma that has a hard dependency on Node somewhere e.g. with a shebang #!/usr/bin/node, or a spawn/exec somewhere.

It's just so odd that it's entirely silent. I guess I'll include Node18 with the container for now, but will spend some time this week to investigate.

[QuentinDutot]

In Docker it fails silently and in local it throws this error:

✘ [ERROR] Could not resolve ".prisma/client/index-browser"

    node_modules/@prisma/client/index-browser.js:1:23:
      1 │ const prisma = require('.prisma/client/index-browser')
        ╵                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path ".prisma/client/index-browser" as external to
  exclude it from the bundle, which will remove this error. You can also
  surround this "require" call with a try/catch block to handle this
  failure at run-time instead of bundle-time.

[judocode]

I have created a repo where Prisma and Bun do not play well in Docker nor non-Docker: https://github.com/judocode/prisma-bun. I currently see the following problem in Docker:

 > [6/6] RUN bun run prisma generate:
16.82 error: "prisma" exited with code 9 (SIGKILL)
------
Dockerfile:11
--------------------
   9 |     COPY . .
  10 |
  11 | >>> RUN bun run prisma generate
  12 |
  13 |     CMD ["bun", "./src/index.ts"]
--------------------
ERROR: failed to solve: process "/bin/sh -c bun run prisma generate" did not complete successfully: exit code: 9

[rmblockcode]

Hi people.

Does somebody have this problem when using docker with prisma and bun?:

 error TS2305: Module '"@prisma/client"' has no exported member 'PrismaClient'.

If a run it locally, this problem doesn't show up! but running docker build, it fails!

[JinYuSha0]

I made a stupid mistake calling cli generate without schema.prisma file
this dockerfile works for me

FROM oven/bun:latest
WORKDIR /usr/src/app

# Install nodejs using n
RUN apt-get -y update; apt-get -y install curl
ARG NODE_VERSION=18
RUN curl -L https://raw.githubusercontent.com/tj/n/master/bin/n -o n \
    && bash n $NODE_VERSION \
    && rm n \
    && npm install -g n
	
COPY bun.lockb package.json ./
RUN bun install
# You must ensure that schema.prisma is already in the directory
COPY . .
RUN bunx prisma generate

RUN bun run build
ENV NODE_ENV production
EXPOSE 3000
ENTRYPOINT [ "bun", "run", "start:prod" ]

[xcaeser]

This is the dockerfile generated by fly.io.
and guess what? it doesn't work :( exactly at the bun run build because it can't find prisma client types
HELP!

# syntax = docker/dockerfile:1

# Adjust BUN_VERSION as desired
ARG BUN_VERSION=1.0.7
FROM oven/bun:${BUN_VERSION} as base

LABEL fly_launch_runtime="Next.js/Prisma"

# Next.js/Prisma app lives here
WORKDIR /app

# Set production environment
ENV NODE_ENV="production"

# Throw-away build stage to reduce size of final image
FROM base as build

# Install packages needed to build node modules
RUN apt-get update -qq && apt-get install -y build-essential openssl pkg-config python-is-python3

# Install node modules
COPY --link bun.lockb package.json ./
RUN bun install

# Generate Prisma Client
COPY --link prisma .
RUN bun prisma generate

# Copy application code
COPY --link . .

# Build application
RUN bun run build

# Remove development dependencies
RUN rm -rf node_modules && bun install --ci

# Final stage for app image
FROM base

# Install packages needed for deployment
RUN apt-get update -qq && apt-get install --no-install-recommends -y openssl && rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Copy built application
COPY --from=build /app /app

# Start the server by default, this can be overwritten at runtime
EXPOSE 3000
CMD [ "bun", "run", "start" ]

[JinYuSha0]

In fact, you also need to install node. Prisma generate needs to generate a node addons.

[cholasimmons]

bunx prisma migrate you mean ?
All is running perfectly for me bro.
Did you relink all mentions of @prisma/client to generated?

[camero2734]

That solution does not work, i tried it. The person who made the blog post must have copied the generated folder into their docker context, so it was already there.

prisma generate does not work without node still.

Yeah, this fix was for a different error that occurred once prisma was actually running, the generator part is still broken unfortunately

[marvinruder]

I have tried using Prisma commands both in the latest canary container and with a locally built version of Bun directly from the main branch some hours ago and I still see Prisma silently failing:

root@4262fb6e72c4:~# bun x prisma init
> Downloading Prisma engines for Node-API for linux-arm64-openssl-3.0.x [====================] 99%root@4262fb6e72c4:~# bun x prisma init
> Downloading Prisma engines for Node-API for linux-arm64-openssl-3.0.x [==========          ] 49%root@4262fb6e72c4:~# bun x prisma init
> Downloading Prisma engines for Node-API for linux-arm64-openssl-3.0.x [==========          ] 49%root@4262fb6e72c4:~#

Sometimes Prisma commands succeed, but only lead to the discovery of other issues. For example, the output of prisma init always ends with

error: Script not found "/tmp/bunx-0-prisma@latest/node_modules/prisma/build/child"

I cannot pinpoint this issue to an exact location in Prisma’s source code, but there is a line in the minified bundle that reads

childPath=path__default.default.join(eval("__dirname"),"child");

Changing child to child.js there removes the error message.

Also, prisma generate fails for me when working with a larger schema. The error shows

Generator "/root/rating-tracker/node_modules/@prisma/client/generator-build/index.js" failed:

13849 | 
13850 | // ../generator-helper/src/generatorHandler.ts
13851 | function generatorHandler(handler) {
13852 |   byline(process.stdin).on("data", async (line) => {
13853 |     console.log(String(line)); // I added this line
13854 |     const json = JSON.parse(String(line));
                         ^
SyntaxError: JSON Parse error: Unterminated string
      at /root/rating-tracker/node_modules/@prisma/client/generator-build/index.js:13854:18
      at /root/rating-tracker/node_modules/@prisma/client/generator-build/index.js:13852:43
      at addChunk (node:stream:1941:43)
      at readableAddChunk (node:stream:1895:59)
      at /root/rating-tracker/node_modules/@prisma/client/generator-build/index.js:13826:12
      at /root/rating-tracker/node_modules/@prisma/client/generator-build/index.js:13838:3
      at final (node:stream:3247:37)
      at callFinal (node:stream:2778:45)

The output from my console.log indeed shows a huge JSON output beginning with {"jsonrpc":"2.0","method":"generate","params":… and ending in the middle of nowhere:

…se,"isNullable":true,"inputTypes":[{"type":"Float","location":"scalar","isList":false},{"type":"Null","location":"scalar","isList":false}]},{"name":"description","isRequired":false,"isNullable":true,"inputTypes":[{"type":"String","location":"scalar","isList":false},{"type":"Null","location":"scalar","isList":false}]},{"name":"marketCap","isRequired":false,"isNullable":true,"inputTypes":[{"type":"Float","location":"scalar","isList":false},{"type":"Null","location":"scalar","isList":false}]}]},{"name":"StockUpdateManyMutationInput","constraints":{"maxNumFields

This is as far as I get. Not sure what to make of all this, I just thought to leave some more information here that might help track down remaining issues. Let me know if you need anything else.

PS: The example above is easily reproducable by using Prisma’s quickstart walkthrough and a non-trivial Schema:

mkdir hello-prisma
cd hello-prisma
bun init -y
bun install typescript ts-node @types/node
bun install prisma
bun x prisma init --datasource-provider sqlite
# now copy some schema to the prisma folder, I used mine from https://github.com/marvinruder/rating-tracker/blob/main/packages/backend/prisma/schema.prisma
bun x prisma generate
# you can add `console.log(String(line));` to node_modules/@prisma/client/generator-build/index.js:13853 to see the json-rpc messages of which parsing fails

[marvinruder]

Still seeing this issue in today’s canary:

docker run --rm -it --entrypoint /bin/sh oven/bun:canary-alpine # also tried with Debian-based oven/bun:canary, same result
/home/bun/app # bunx prisma init
> Downloading Prisma engines for Node-API for linux-musl-arm64-openssl-3.0.x [=================   ] 87%/home/bun/app # 
/home/bun/app # bun --revision
1.0.29+2fb6733ee
/home/bun/app # 

[Jarred-Sumner]

Confirming this issue is still not fixed. The previous PRs made good progress, but prisma generate continues to not work when used in Bun.

"Downloading" hangs or exits prematurely, before it finishes:

❯ bun --bun prisma generate
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
> Downloading Prisma engines for Node-API for darwin-arm64 [==============      ] 69%

In a debug build, those logs look like this

[MEM] free(6824153) = 10240862
[fetch] onData 177937
[fetch] progressUpdate true
[fetch] releaseSocket(0x00006000010184D0)
[fetch] Keep-Alive release binaries.prisma.sh:443 (0x105553133143248)
[fetch] onAsyncHTTPCallback: 182.198ms
[FetchTasklet] callback success true has_more false bytes 177937
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 2599) = 2599
[FileSink] Wrote 2599 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/180224)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/196608)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/212992)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 12778) = 12778
[FileSink] Wrote 12778 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/225770)
[SYS] write(1, 4) = 4
[FileSink] Wrote 4 bytes (fd: 1, head: 0, 0/105)
> Downloading Prisma engines for Node-API for darwin-arm64 [                    ] 1%[SYS] write(1, 93) = 93
[FileSink] Wrote 93 bytes (fd: 1, head: 0, 0/198)
[SYS] write(1, 4) = 4
[FileSink] Wrote 4 bytes (fd: 1, head: 0, 0/202)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 3606) = 3606
[FileSink] Wrote 3606 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/229376)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/245760)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/262144)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 5189) = 5189
[FileSink] Wrote 5189 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/267333)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 11195) = 11195
[FileSink] Wrote 11195 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/278528)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/294912)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 1242) = 1242
[FileSink] Wrote 1242 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/296154)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 15142) = 15142
[FileSink] Wrote 15142 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/311296)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/327680)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 1430) = 1430
[FileSink] Wrote 1430 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/329110)
[FetchTasklet] onProgressUpdate
[Loop] sub 1 - 1 = 0
[FetchTasklet] clearData
[MEM] free(122) = 10240740
[MEM] free(128) = 10240612
[MEM] free(73) = 10240539
[MEM] free(430) = 10240109
[MEM] free(384) = 10239725
[MEM] free(10236237) = 3488
[FetchTasklet] deinit
[MEM] free(2688) = 800
[MEM] free(800) = 0
[SYS] write(1, 4) = 4
[FileSink] Wrote 4 bytes (fd: 1, head: 0, 0/206)
> Downloading Prisma engines for Node-API for darwin-arm64 [                    ] 2%[SYS] write(1, 93) = 93
[FileSink] Wrote 93 bytes (fd: 1, head: 0, 0/299)
[SYS] write(1, 4) = 4
[FileSink] Wrote 4 bytes (fd: 1, head: 0, 0/303)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 14954) = 14954
[FileSink] Wrote 14954 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/344064)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/360448)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 7141) = 7141
[FileSink] Wrote 7141 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/367589)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 9243) = 9243
[FileSink] Wrote 9243 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/376832)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 16384) = 16384
[FileSink] Wrote 16384 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/393216)
[SYS] write(45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], 5046) = 5046
[FileSink] Wrote 5046 bytes (fd: 45[/private/var/folders/hd/k_cxl9f55475q62m8_f_9k_c0000gn/T/3179ff6fa0b860d374338cd1441ca7e3/partial], head: 0, 0/398262)

This issue will only reproduce when prisma engines have not yet been downloaded on the machine, like when using Docker and the Prisma engine is not cached on-disk.

There is also an issue when prisma calls child_process.fork but I'm not able to isolate it yet.

[camero2734]

The issue now seems to be with node-fetch. Here's a minified repro:

import hasha from "hasha"; // bun add [email protected]
import zlib from "zlib";
// import fetch from "node-fetch";
import fetch from "./node_modules/node-fetch/lib/index.mjs"; // bun add [email protected]

async function downloadZip(url2) {
  const response = await fetch(url2, { compress: false });
  if (!response.ok) throw new Error('fail');

  return await new Promise(async (resolve3, reject2) => {
    let bytesRead = 0;
    response.body
      .on("error", reject2)
      .on("data", (chunk) => { bytesRead += chunk.length });
    const gunzip = zlib.createGunzip();
    gunzip.on("error", reject2);
    const zipStream = response.body.pipe(gunzip);
    const zippedHashPromise = hasha.fromStream(response.body, { algorithm: "sha256" });
    const hashPromise = hasha.fromStream(zipStream, { algorithm: "sha256" });
    console.log("will await");
    await hashPromise;
    await zippedHashPromise;
    console.log("all okay");
    resolve3();
  });
}

const url = "https://binaries.prisma.sh/all_commits/5a9203d0590c951969e85a7d07215503f4672eb9/debian-openssl-1.1.x/libquery_engine.so.node.gz";
const array = new Array(10).fill(url);

const promises = array.map((url) => downloadZip(url));

await Promise.all(promises);
console.log("DONE");

This will never log DONE, it will hang after 4 or so all okay logs.

Note that I use the explicit node-fetch import because Prisma bundles the OG node-fetch with it, which means it isn't replaced with Bun's version (if you swap it out for the commented-out import, it will work and reach DONE).

Haven't dug any deeper than this atm, but this narrows it down quite a bit

[xcaeser]

switched to drizzle after all.

[neilsong]

With bun 1.0.31, prisma generate does not work with a non-trivial schema already in docker context, hanging without exiting.

# bunx prisma generate
Prisma schema loaded from prisma/schema.prisma

All subsequent prisma generate commands after interrupting the first process exit silently.

[ThallesP]

@Jarred-Sumner I'm still getting issues where Prisma silently fails, shouldn't this issue be open?

no output or anything.
is there anything that Bun can do to atleast show some info while this isnt fixed? i've spent 2hours today trying to debug this.
and also can confirm, with node binary prisma works without any problem.

[zackify]

yeah, there is no output running bunx prisma migrate deploy still.

[fzn0x]

I wasted so many times on this, I hope we can get better solutions soon 😄

[roobr]

I am also having this issue

[the-dream-machine]

This issue is still present in v1.1.13. @Jarred-Sumner can we reopen this?

[the-dream-machine]

If anyone is looking for a sample Dockerfile to use before this is fixed, this one worked for me:

# Set Bun and Node version
ARG BUN_VERSION=1.1.13
ARG NODE_VERSION=20.12.2
FROM imbios/bun-node:${BUN_VERSION}-${NODE_VERSION}-slim

# Set production environment
ENV NODE_ENV="production"

# Bun app lives here
WORKDIR /app

# Copy app files to app directory
COPY . .

# Install node modules
RUN bun install

# Generate Prisma Client
RUN bun prisma generate

# Start the server by default, this can be overwritten at runtime
EXPOSE 3000
CMD [ "bun", "run", "start" ]

This image contains both bun and node.js. The slim variant strips out all the unnecessary files. Good luck traveler :)

[amir-s]

I can confirm this is still an issue. bunx prisma -v, bunx prisma generate and most other commands fail silently.
Adding COPY --from=node:20 /usr/local/bin/node /usr/local/bin/node to the docker file solved the issue for now.

[cholasimmons]

I believe it works starting from version 1.1.13 up to .16.
Remember Prisma is a devDependency so trying to run that code in production should fail.

[amir-s]

Remember Prisma is a devDependency so trying to run that code in production should fail.

Mostly yes. But the migrations are also a production concern and bunx prisma migration deploy fails as well.

[cholasimmons]

Well yes but you're still trying to use a program that's non existent due to the environment you're in (Prisma in production).
One way could be to copy the migrations SQL file(s) to a location where you can directly execute it into the database. This is usually what happens when deploying to the cloud anyways

[Jarred-Sumner]

To those of you running into this issue in more recent versions of Bun -- please provide some kind of reproduction and open a new issue. The original cause was fixed (and I've manually verified it continues to work in a simple case), but that means we need more information in order to address any new issues you're running into.

Also, if you're using Alpine Linux, it will likely not work until #918 is addressed.