Skip to content

feat: Allow to set Prisma Engine directory in config #1815

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
luap2703 opened this issue Mar 23, 2025 · 3 comments
Closed

feat: Allow to set Prisma Engine directory in config #1815

luap2703 opened this issue Mar 23, 2025 · 3 comments

Comments

@luap2703
Copy link

luap2703 commented Mar 23, 2025

Provide environment information

System:
OS: macOS 15.2
CPU: (12) arm64 Apple M2 Pro
Memory: 74.70 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.19.0 - /opt/homebrew/bin/node
Yarn: 4.5.1 - /opt/homebrew/bin/yarn
npm: 10.8.2 - /opt/homebrew/bin/npm

Describe the bug

For the prismaExtension, it is currently not possible to define the path/directory of the engine files required to run.

We're having a large monorepo and the engine file is nested.

While we can copy it using:

   additionalFiles({
                files: [
                    "packages/core/core-prisma/node_modules/.prisma/client/libquery_engine-darwin-arm64.dylib.node",
                ],
            }),

prisma won't search in the copied directory.

Three ways to mitiage this would be:

  1. Allowing the additionalFiles to not only define the file directory, but also a relative path where to copy it into the .trigger folder
 additionalFiles({
                files: [
                    { from: "abc/def", to: "tmp/put_it_here" },
                ],
            }),,
  1. Add a additionalFiles prop to the prisma exension, allowing for copying the files or setting env variables for the run
  2. Set the env variable as PRISMA_QUERY_ENGINE_LIBRARY for prisma, but this isn't really possible for us as it is clashing with other parts/deployments of the repo

Reproduction repo

To reproduce

Demo setup + move the engine file somewhere.

Additional information

This is truly one of the greatest projects we've seen for a long time(!!!). We have been spending literally MONTHS in time on debugging and running AWS lambdas, eventually moving to batch/fargate tasks, step functions, etc. etc..

The dev experience is 1000x better! Props on you!

@ericallam
Copy link
Member

@luap2703 I think this is an issue where we cannot detect the prisma version so it doesn't correctly install during deploy: #1809

If you manually specify the version in the prismaExtension call it should work

@D-K-P
Copy link
Member

D-K-P commented Mar 23, 2025

So to add to what @ericallam said, something like this @luap2703:

build: {
    extensions: [
      prismaExtension({
        // The version you're using
        version: "6.5.0",
        // Your schema relative path
        schema: "../../packages/database/prisma/schema.prisma",
      }),
    ],
  },

@luap2703
Copy link
Author

You're right! Seems to work now, was eventually some weird behavior when initializing trigger the first time (probably smth related to our repo, sorry for bothering(!!))

One more follow-up feature request/feedback ^^:

We're currently using quite a lot of prisma schema files (see image). I figured out that it is important to mention all in the prismaExtension as the deployment otherwise fails. Instead of mentioning all individually, we came up with this:

import { PrismaInstrumentation } from "@prisma/instrumentation";
import { additionalPackages } from "@trigger.dev/build/extensions/core";
import { prismaExtension } from "@trigger.dev/build/extensions/prisma";
import { defineConfig } from "@trigger.dev/sdk/v3";
import fs from "fs";
import path from "path";

const corePrismaDir = "./packages/core/core-prisma/prisma/schema";

function getPrismaSchemaFiles(dir: string): string[] {
    const files: string[] = [];

    try {
        fs.readdirSync(dir).forEach((file) => {
            const filePath = path.join(dir, file);
            if (fs.statSync(filePath).isFile() && file.endsWith(".prisma")) {
                files.push(filePath);
            }
        });

        // For some reason is called 2 times and failes for the second time, perhaps the config is called from another place again
    } catch (e) {
        console.error("Error reading prisma schema files", e);
    }

    return files;
}

const prismaSchemaFiles = getPrismaSchemaFiles(corePrismaDir);

console.log("Prisma schema files:", JSON.stringify(prismaSchemaFiles, null, 2));

const prismaExtensions = prismaSchemaFiles.map((schemaFile) => {
    return prismaExtension({
        version: "5.22.0", // Ensure this version is correct for all schemas
        schema: schemaFile,
        clientGenerator: "client",
        directUrlEnvVarName: "PRISMA_DIRECT_URL", // Or determine this dynamically if needed
    });
});

export default defineConfig({
    project: "proj_rksruogwyvcubhhibefq",
    runtime: "node",
    logLevel: "log",
    // The max compute seconds a task is allowed to run. If the task run exceeds this duration, it will be stopped.
    // You can override this on an individual task.
    // See https://trigger.dev/docs/runs/max-duration
    maxDuration: 3600,

    instrumentations: [new PrismaInstrumentation()],

    build: {
        extensions: [
            additionalPackages({
                packages: ["prisma-kysely"],
            }),
            ...prismaExtensions,
        ],
    },
});

Perhaps it would also be helpful for others to integrate something similar with a small "isMultiSchema: boolean" flag on the extension (perhaps allowing for multiple file directories where all files ending on .prisma are mentioned).

Nevertheless, insanely great dev-experience(!!!!)

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants