Gathering detailed insights and metrics for prisma-kysely
Gathering detailed insights and metrics for prisma-kysely
Gathering detailed insights and metrics for prisma-kysely
Gathering detailed insights and metrics for prisma-kysely
🪄 Generate Kysely types directly from your Prisma schema!
npm install prisma-kysely
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
953 Stars
91 Commits
36 Forks
5 Branches
15 Contributors
Updated on 25 Nov 2024
TypeScript (99.12%)
JavaScript (0.88%)
Cumulative downloads
Total Downloads
Last day
-12.7%
15,687
Compared to previous day
Last week
-2.1%
89,661
Compared to previous week
Last month
30.4%
290,353
Compared to previous month
Last year
956.8%
1,932,322
Compared to previous year
20
🚧 Library and README in progress...
Do you like Prisma's migration flow, schema language and DX but not the limitations of the Prisma Client? Do you want to harness the raw power of SQL without losing the safety of the TypeScript type system?
Enter prisma-kysely
!
Install prisma-kysely
using your package manager of choice:
1yarn add prisma-kysely
Replace (or augment) the default client generator in your schema.prisma
file with the following:
1generator kysely { 2 provider = "prisma-kysely" 3 4 // Optionally provide a destination directory for the generated file 5 // and a filename of your choice 6 output = "../src/db" 7 fileName = "types.ts" 8 // Optionally generate runtime enums to a separate file 9 enumFileName = "enums.ts" 10}
Run prisma migrate dev
or prisma generate
and use your freshly generated
types when instantiating Kysely!
Prisma's migration and schema definition workflow is undeniably great, and the typesafety of the Prisma client is top notch, but there comes a time in every Prisma user's life where the client becomes just a bit too limiting. Sometimes we just need to write our own multi table joins and squeeze that extra drop of performance out of our apps. The Prisma client offers two options: using their simplified query API or going all-in with raw SQL strings, sacrificing type safety.
This is where Kysely shines. Kysely provides a toolbox to write expressive,
type-safe SQL queries with full autocompletion. The problem with Kysely though
is that it's not super opinionated when it comes to schema definition and
migration. What many users resort to is using something like Prisma to define
the structure of their databases, and kysely-codegen
to introspect their
databases post-migration.
This package, prisma-kysely
, is meant as a more integrated and convenient way
to keep Kysely types in sync with Prisma schemas. After making the prerequisite
changes to your schema file, it's just as convenient and foolproof as using
Prisma's own client.
I've been using this combo for a few months now in tandem with Cloudflare's D1 for my private projects and Postgres at work. It's been a game-changer, and I hope it's just as useful for you! 😎
Key | Description |
---|---|
output | The directory where generated code will be saved |
fileName | The filename for the generated file |
enumFileName | The filename for the generated enums. Omitting this will generate enums and files in the same file. |
camelCase | Enable support for Kysely's camelCase plugin |
readOnlyIds | Use Kysely's GeneratedAlways for @id fields with default values, preventing insert and update. |
[typename]TypeOverride | Allows you to override the resulting TypeScript type for any Prisma type. Useful when targeting a different environment than Node (e.g. WinterCG compatible runtimes that use UInt8Arrays instead of Buffers for binary types etc.) Check out the config validator for a complete list of options. |
In some cases, you might want to override a type for a specific field. This could be useful, for example, for constraining string types to certain literal values. Be aware though that this does not of course come with any runtime validation, and in most cases won't be guaranteed to match the actual data in the database.
That disclaimer aside, here's how it works: Add a @kyselyType(...)
declaration
to the Prisma docstring (deliniated using three slashes ///
) for the field
with your type inside the parentheses.
1model User { 2 id String @id 3 name String 4 5 /// @kyselyType('member' | 'admin') 6 role String 7}
The parentheses can include any valid TS type declaration.
The output for the example above would be as follows:
1export type User = { 2 id: string; 3 name: string; 4 role: "member" | "owner"; 5};
By default (no pun intended) the Prisma Query Engine uses JS based
implementations for certain default values, namely: uuid()
and cuid()
. This
means that they don't end up getting defined as default values on the database
level, and end up being pretty useless for us.
Prisma does provide a nice solution to this though, in the form of
dbgenerated()
. This allows us to use any valid default value expression that
our database supports:
1model PostgresUser { 2 id String @id @default(dbgenerated("gen_random_uuid()")) 3} 4 5model SQLiteUser { 6 id String @id @default(dbgenerated("(uuid())")) 7}
Check out the Prisma Docs for more info.
OMG you actually want to contribute? I'm so thankful! 🙇♂️
Here's everything you need to do (let me know if something's missing...)
yarn install
and yarn dev
to start tsc
in watch mode.prisma/schema.prisma
, running yarn prisma generate
and checking the output in prisma/types.ts
. The provider must be set
as follows to reference the dev build:
1generator kysely { 2 provider = "node ./dist/bin.js" 3}
I'm not 100% sure the type maps are correct for every dialect, so any and all contributions on that front would be greatly appreciated. The same goes for any bug you come across or improvement you can think of.
prisma-dbml-generator
.
Many-too-many thanks to them!1+ Boyce-Codd gang unite! 💽
No vulnerabilities found.
No security vulnerabilities found.