Request for user feedback about @prisma/sdk (renamed to @prisma/internals with Prisma 4)

[Jolg42]

Note: We renamed our @prisma/sdk package to @prisma/internals with Prisma 4.0.0 (released on June 28th).

The @prisma/sdk package was meant as a Prisma internal package only, but it leaked out over time and is now used across many community tools and packages.

With the rename of the npm package we want to make it clearer that we can not give any API guarantees for @prisma/internals, might need to introduce breaking changes to the API from time to time and will not follow semantic versioning (breaking changes only in major upgrade) with it. We think that it is better communicated with internals than with sdk.

Here you could help us gain an understanding where, how and why you are using @prisma/sdk (now @prisma/internals) to achieve, what exactly.

Your feedback will be valuable to us in defining a better API.

Looking forward to your feedback,
Your friends at Prisma 💚

[Jolg42]

Originally posted by @marcjulian in notiz-dev/prisma-dbml-generator#34 (comment)

I'm using @prisma/sdk once in the generator and twice for test utils.

Generator

Parsing generator config output, as suggested in notiz-dev/prisma-dbml-generator#9

https://github.com/notiz-dev/prisma-dbml-generator/blob/b5969a332eb0bacdd3f405e8d14385ccf77f5d78/src/cli/dbml-generator.ts#L2

https://github.com/notiz-dev/prisma-dbml-generator/blob/b5969a332eb0bacdd3f405e8d14385ccf77f5d78/src/cli/dbml-generator.ts#L14

Test Utils

For tests the following utils use @prisma/sdk:

Generates DMMF based on the provided Prisma schema

https://github.com/notiz-dev/prisma-dbml-generator/blob/b5969a332eb0bacdd3f405e8d14385ccf77f5d78/__tests__/utils/generateDMMF.ts#L1-L6

Creates the generator config for the provided generator dbml block

https://github.com/notiz-dev/prisma-dbml-generator/blob/b5969a332eb0bacdd3f405e8d14385ccf77f5d78/__tests__/utils/generateConfig.ts#L1-L5

Any suggestions if those functionalities are already provided by a different package, which should be used for a community generator?

[Jolg42]

Originally posted by @valentinpalkovic in valentinpalkovic/prisma-json-schema-generator#548 (comment)

There are exactly two places, where @prisma/sdk is currently in use.

First usage: https://github.com/valentinpalkovic/prisma-json-schema-generator/blob/e7aca4a21f9d8a04d7a238f6b720a804645eef7c/src/index.ts#L22
Here I am using it to parse the output-dir. Maybe there is already a more elegant way to do so and it is not required to use the @prisma/sdk here at all.

Second usage: https://github.com/valentinpalkovic/prisma-json-schema-generator/blob/530b9b90ed19c7dc75d0a327130a5a7469b6c5de/src/tests/generator.test.ts#L66
Here I am using getDMMF from @prisma/sdk to transform a Prisma model (string template) into an object to test my internal transformDMMF transformer.

[Jolg42]

Originally posted by @maoosi in maoosi/prisma-appsync#42 (comment)

Removing @prisma/sdk entirely from Prisma-AppSync will not be an issue, as I’m only using it for its parseEnvValue function (which I was planning to remove in the next coming release). I am also not using Prisma.dmmf from @prisma/client anywhere.

Prisma-AppSync is mainly reliant on generatorHandler and DMMF exported from @prisma/generator-helper package, as well as the GeneratorOptions available from the generatorHandler :: onGenerate handler. I am reading the dmmf.datamodel property from there.

Any changes planned on the above?

[Jolg42]

Originally posted by @YassinEldeeb in:
YassinEldeeb/prisma-tgql-types-gen#51 (comment)
YassinEldeeb/create-prisma-generator#134 (comment)
YassinEldeeb/create-prisma-generator#134 (comment)

Here I'm just using your logger function that makes it look colorful when it automatically installs packages and generates the code.

Next Steps

I'll just copy your logger module into my source code and exclude @prisma/sdk from my dependencies, cause It's not at all worth installing the whole package and you've said that anything can break at any time.

I guess the Prisma SDK Reference will get you a super helpful overview of what people are currently using in @prisma/sdk. These documented ones are by far the most important and commonly used modules in @prisma/sdk from a community perspective.

Basically getDMMF is the most essential utility for almost everyone, cause it's the only convenient way to parse a datamodel into an AST aka DMMF to check the transformation logic of the generator in testing suites. Everything else are just simple wrappers around existing libraries like isCI, chalk, node fs, etc...

[Jolg42]

Originally posted by @omar-dulaimi in omar-dulaimi/prisma-yup-generator#10 (comment)

Thanks for the heads up. I agree that internals is a better name for something that could break every now and then. The old name sdk conveyed that it was something Prisma exposed for the developers out there for use, like my projects for example.

I currently do use Prisma.dmmf, I appreciate letting me know about the alternative (using getDmmf()).

The @prisma/internals is super useful in the context of generators. I see it as one of Prisma's greatest selling points. We're not limited by the features the Prisma team builds(we are very appreciative of). The community can always come up with creative and interesting ways a piece of software can be used.

One thing I'd like to see in the future is input object types with model attributes. Currently they are separated, and manual work has to be done in order to produce schemas that have the same attributes like the model fields. Like

isUnique
isId
isReadOnly
hasDefaultValue
default
isGenerated
isUpdatedAt 

Thank you for making Prisma great.

[franky47]

I use getDMMF from @prisma/sdk in my field encryption middleware in tests to build a DMMF object to test my parsers against, using a test schema. It's definitely not an ideal setup, and I'll probably move away from it when updating the middleware for v4 compatibility.

Another question I have is regarding logging. There's a disclaimer that links to this issue in @prisma/debug, and I'd like to provide some debug info to the middleware users. Would you recommend this package or another solution?

[Jolg42]

Merci @franky47! Note about getDMMF(), it is still present in the @prisma/internals package, so you could continue using it from there.

@prisma/debug is actually a slightly modified version of the debug package you can find on npm. So I would recommend switching to that or anything else that might fit your needs.

[tmtron]

We use get-platform to build the engine-filenames. This is needed when we want to run prisma and the migrations when our Electorn app starts: see #9613 (comment)

[janpio]

Can you expand on how and why you run migrations directly via the engine filenames?

[tmtron]

Why

Our Electron app stores data on the client in a SQLite database. When the app is updated, it must execute the schema-migration on app-start.

• Prisma Migrate: programmatic access to CLI commands (deploy, reset...) #4703: There is no API to start the migration
• Can not spawn Query Engine when using Electron #9619: PrismaClient cannot automatically detect the binary in the Electron app

How

We fork a new node process and execute node_modules/prisma/build/index.js migrate deploy --schema PATH and pass the relevant env-vars:

• PRISMA_MIGRATION_ENGINE_BINARY
• PRISMA_QUERY_ENGINE_LIBRARY
• PRISMA_FMT_BINARY

[vadimdemedes]

I would like to use Prisma for a SQLite database in my Electron app, so I would love an API for manually running pending migrations when the app starts. Is something like this possible today?

[Jolg42]

Electron would probably not work out of the box though 🤔
I recommend checking this issue #9613
and for example this comment #9613 (comment)

[diced]

Ive been using @prisma/sdk as a indirect dependency of @prisma/migrate as I need access to the migration engine, which I'd prefer not to execute prisma migration deploy since the api gives more control and makes it easier, see my repo here: https://github.com/diced/zipline/blob/trunk/src/server/util.ts#L7-L27

[tmtron]

Nice. I didn't know that @prisma/migrate exists. If this was a stable public package, I'd also use it instead of forking the migration engine process by myself.

[diced]

So far I haven't had any problems with the package, and if there were any problems they would probably be in the official CLI anyway, since it also uses the package, so I do think it's stable enough to run.

[birgersp]

We have a database that was created long before anyone in my team knew about prisma. So all constraints and indexes (among other things) are "improperly" named. If we were to start over we would name them according to prisma naming scheme.

So we would like to be able to parse the schema.prisma file, and list all the "map" entries that exist. Then it would be really trivial to generate the necesarry queries to properly rename everything.

[felzix]

I want to run tests that alter the database. So I need to do whatever prisma db push is doing to populate the test database with tables.

[juliusmarminge]

I recently created a generator which outputs my enums to a separate entry point that I could use on the client.

I used your generator helper for this which made it really easy, it was a great experience. Would love for it to be documented

[abrl91]

In our case, Amplication, we are using it for another package that we maintain:
prisma-schema-dsl, a package that helps you generate Prisma schema.
We only use the formatSchema methotd.

Recently, we had a problem with the CI workflow.

It all started when we made 2 changes that, at first, seemed to be unrelated to each other, but now we know that these two changes are indeed related.

1. we upgraded our Prisma and @prisam/client form version 3.15.2 to 4.6.1. This PR passed the CI, but after merging it to our development branch (we call it next), the CI failed with the following error:

Error: Could not find prisma-fmt binary. Searched in /home/runner/work/amplication/amplication/packages/amplication-data-service-generator/node_modules/@prisma/sdk/prisma-fmt-debian-openssl-3.0.x and /home/runner/work/amplication/amplication/packages/amplication-data-service-generator/node_modules/@prisma/prisma-fmt-debian-openssl-3.0.x
          at resolveBinary (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/node_modules/@prisma/sdk/dist/resolveBinary.js:93:9)
          at Object.formatSchema (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/node_modules/@prisma/sdk/dist/engine-commands/formatSchema.js:41:25)
          at createPrismaSchemaInternal (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/server/prisma/create-prisma-schema.ts:76:13)
          at defaultBehavior (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/plugin-wrapper.ts:41:7)
          at pluginWrapper (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/plugin-wrapper.ts:68:36)
          at createPrismaSchema (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/server/prisma/create-prisma-schema.ts:31:10)
          at createPrismaSchemaModule (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/server/prisma/create-prisma-schema-module.ts:8:10)
          at createServerInternal (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/server/create-server.ts:122:30)
          at async Promise.all (index 0)
          at createDataServiceImpl (/home/runner/work/amplication/amplication/packages/amplication-data-service-generator/src/create-data-service-impl.ts:38:5) {"timestamp":"2022-11-26T16:59:28.846Z"}

We read that Prisma supports open-SSL-3 from one of its earliest versions 3, so this was strange, but following the stack trace, we noticed that the error comes from formatSchema and resolveBinary. These methods are called from one of our libraries:
prisma-schema-dsl. One of the dependencies of this package is @prisma/sdk, which as you said, was deprecated and moved to @prisma/internals.

2. Few days before we upgraded to Prisma 4.6.1, we released a new version of prisma-schema-dsl (for mongo support).

Following the stack trace, and the fact that @prisms/sdk was deprecated, we decided to uninstall it and install @prisma/internals. So now we are using the formatSchema form @prisma/internals

After this change, (and some other changes on prisma-schema-dsl that are not related to Prisma), we updated our packages that depend on prisma-schema-dsl and the problem was solved.

[septatrix]

For my purposes I require the SDK (or more specifically @prisma/migrate) to programmatically apply migrations and initialize the DB. A stable, public API would be great for that as discussed in #4703.

[timReynolds]

We've used @prisma/generator-helper and "@prisma/sdk to generate test utils. A single library currently generates two things;

• Fixtures for the generated types so you can generate say a User with test data
• Seed and destroy methods building on the above to make integration testing easier

[QuantumGlitch]

I'm actually using @prisma/internals to generate prisma schema in a pragmatical way using projen:

• I defined a structure to create a prisma schema
• I defined functionalities to auto generate log tables with a similar structure the original ones
• After all the processing I need to format the schema

e.g.

export enum PrismaObjectTypeDefinition {
  MODEL = "model",
  ENUM = "enum",
}

export type EnumDefinition = {
  type: PrismaObjectTypeDefinition.ENUM;
  name: string;
  values: string[];
};

export type ModelFieldDefinition = {
  name: string;
  type: string;
  modifier?: string;
};

export type ModelDefinition = {
  type: PrismaObjectTypeDefinition.MODEL;
  name: string;
  fields: ModelFieldDefinition[];
  modifiers?: string[];
};

export type PrismaObjectDefinition = EnumDefinition | ModelDefinition;

export type PrismaSchemaDefinition = PrismaObjectDefinition[];


function formatEnum(obj: EnumDefinition) {
  return `enum ${obj.name}{
${obj.values.join(" \n")}
  }`;
}

function formatModel(obj: ModelDefinition) {
  return `model ${obj.name}{
    ${obj.fields
      .map((f) => `${f.name} ${f.type} ${f.modifier ?? ""}`)
      .join(" \n")}
    ${obj.modifiers?.join("\n") ?? ""}
  }`;
}

function formatObject(obj: PrismaObjectDefinition) {
  switch (obj.type) {
    case PrismaObjectTypeDefinition.ENUM:
      return formatEnum(obj);
    case PrismaObjectTypeDefinition.MODEL:
      return formatModel(obj);
  }
}

function generate(definition: PrismaSchemaDefinition){
    const schemaContent = `datasource db {
      provider = "mysql"
      url      = env("DATABASE_URL")
    }
    
    generator client {
      provider = "prisma-client-js"
      output          = "client"
      binaryTargets   = ["native", "rhel-openssl-1.0.x", "linux-musl"]
    }
    
    ${
      definition
        ? definition
            .map((obj) => formatObject(obj))
            .join("\n")
        : ""
    }
    `;

    return formatSchema(schemaContent);
}

[dougwithseismic]

Using it to generate express routes and swagger docs from a prisma.schema file. It's awesome, honestly.

[dylel]

I came here looking to extend "Prisma Kysely", which uses the @prisma/generator-helper. For some reason the generatorHandler doesn't parse in unsupported columns. I was trying to use prisma for database schema management with an unsupported type of "Geometry" in sql server, and then using kysely to insert/read the values correctly in the format a driver would understand. I wished to override the type in "Prisma Kyseley" and map it to a string, i.e the format the underlying driver would understand. Is there a reason the generatorHandler is filtering out Unsupported columns?

[MBrunoS]

Hello there! I'm using it to build a Next.js CRUD generator, based on the models (options.dmmf.datamodel)

[michaeleichmann]

same use case here as well! CRUD form generator based on schema.

[vstlouis]

Same here! Shad cn forms..

[emilio-toledo]

Hey everyone, I am using the definitions from @prisma/generator-helper for Oxigen

[therebelrobot]

Hi all! I'm using this to parse my prisma schema and generate a corresponding mermaid.js diagram

[dennemark]

I am using this because of the following issue:
#23093

[lucafaggianelli]

Hey there, I'm using formatSchema from @prisma/sdk just to format a schema that I generate myself as part of my app

[leighman]

We are using @prisma/migrate to interact with testcontainers for integration testing against a local database

[bengouss]

We are using @prisma/migrate to programmatically run migrations on different databases on a multi-tenant application. Each tenant has its own database, with different servers/credentials.

[kpostekk]

We are using @prisma/migrate to programmatically run migrations in test containers, while deploying in network-scarce docker containers and to reduce number of actions to perform while starting/updating multiple edge applications.

We are also using @prisma/engine to download binaries without installing prisma package.

[matmar10]

We are using @prisma/internals (specifically, getDMMF) to serialize/deserialize bigint and decimals properly in queries and responses sent across AMQP (RabbitMQ) via JSON.

[Zitrooone]

We intend to use @prisma/migrate to run migrations in a Docker container with a standalone Next app. Currently we install the full prisma package into the image to have access to the migration commands on startup, but this adds a lot of weight to the image. Ideally, @prisma/migrate would offer a light weight alternative. Haven't gotten around to testing it yet.
Since I was not able to find much information on running migrations with a setup like ours, any guidance would be appreciated.