Update Prisma to v5 #2231

infomiho · 2024-08-08T11:48:10Z

Closes #1281
Closes #1570
Closes #2099

Left to do

infomiho · 2024-08-14T11:22:56Z

waspc/data/Generator/templates/sdk/wasp/server/crud/_operationTypes.ts

@@ -103,7 +103,12 @@ export type CreateActionResolved = typeof _waspCreateAction

 {=# crud.operations.Update =}
 {=^ overrides.Update.isDefined =}
-type UpdateInput = Prisma.{= crud.entityUpper =}UpdateInput & Prisma.{= crud.entityUpper =}WhereUniqueInput
+type UpdateInput = Prisma.XOR<


Fixes UpdateInput to match what Prisma Client expects.

infomiho · 2024-08-14T11:33:22Z

waspc/data/Generator/templates/sdk/wasp/prisma-runtime-library.d.ts

@@ -0,0 +1,14 @@
+// Without this import, Prisma types are resolved incorrectly.


@sodic this is the fix I implemented in the end, it slightly nudges the FieldRef type to work with our SuperJSON serialization.

I went down the rabbit hole of recursively converting all interfaces into types using Pick<T, keyof T> (as suggested by some in the Github issue) but this ended up being less problematic and simple enough.

The code comment doesn't fully explain what's happening and what the tradeoffs are. Do you mind adding this playground link too.

It currently implies that type types have an implicit index signature (which isn't really true, they only exhibit special subtyping behavior). The comment also doesn't mention the compromise we made by declaring an extension to the FieldRef interface.

Anyway, both things should be clear from the playground, and you can adjust it as you see fit.

BTW, what happend with trying to fix the root of the problem, the definition of the JSONSerializable type (as attempted here). Did Superjson make it too complex?

I've updated the comment to mention the playground to make it more complete as an explanation.

BTW, what happend with trying to fix the root of the problem, the definition of the JSONSerializable type (as attempted here). Did Superjson make it too complex?

We concluded that JSONSerializable would stop users from using the Prisma field reference feature: https://www.prisma.io/docs/orm/reference/prisma-client-reference#compare-columns-in-the-same-table since the proposed approach drops fields.

Then we set on to recursively convert all interfaces to types - which in the end was a long way of doing this d.ts patch we have in this repo.

infomiho · 2024-08-14T11:33:40Z

waspc/data/Generator/templates/sdk/wasp/server/crud/_operationTypes.ts

@@ -91,7 +91,10 @@ export type GetQueryResolved = typeof _waspGetQuery

 {=# crud.operations.Create =}
 {=^ overrides.Create.isDefined =}
-type CreateInput = Prisma.{= crud.entityUpper =}CreateInput
+type CreateInput = Prisma.XOR<


Fixes CreateInput to match what Prisma Client expects.

I trust this is correct, but can you give more details?

Asking just out of curiosity.

I copied the type the create method has defined for its data input. Before I only used the simpler type because I thought it was enough, but now I realise it's better to follow 1:1 what Prisma uses internally - users will get the same type as if they were using create directly themselves.

infomiho · 2024-08-14T11:34:42Z

waspc/data/Generator/templates/server/src/crud/_operations.ts

@@ -39,9 +50,7 @@ const entities = {
 // 1. We either use the default implementation of the operation...
 =}
 {=^ overrides.GetAll.isDefined =}
-type GetAllInput = {}


For some reason, we built these types in two places: in the server and the in the SDK, but there was no need since the server can import the built types from the SDK. This change ensures that CRUD operation types are coming one a single source of truth.

infomiho · 2024-08-14T11:35:14Z

waspc/examples/crud-testing/schema.prisma

@@ -1,5 +1,5 @@
 datasource db {
-  provider = "sqlite"
+  provider = "postgresql"


Mistake that was left after the migration to schema.prisma file. I'm not sure how that got through.

infomiho · 2024-08-14T11:36:40Z

waspc/examples/todoApp/src/testTypes/operations/client.ts

-  Equal<
-    typeof taskToTaskUnspecified,
-    (args: Task) => ReturnType<typeof taskToTaskUnspecifiedDefinition>
+  Expect<


These tests now pass 👍

infomiho · 2024-08-14T11:55:35Z

waspc/examples/todo-typescript/src/jobs/print.ts

@@ -5,6 +5,6 @@ export const printTimeAndNumberOfTasks: PrintTimeAndNumberOfTasks<
  {},
  void
 > = async (data, context) => {
-  const count = await getTotalNumberOfTasks(null, context)
+  const count = await getTotalNumberOfTasks()


This broke after the last operations API update, quick fix.

Signed-off-by: Mihovil Ilakovac <[email protected]>

Martinsos

Cool stuff @infomiho ! I will leave it to @sodic to check the Typescript stuff. The rest is looking good to me.
I assume you did a "diff" between the Prisma version we were on and Prisma 5, by checking their Changelog -> is there anything new we should be adding support for in Wasp, or taht significantly changed? Seems from this PR that not much changed on the API level?

Martinsos · 2024-08-29T15:22:47Z

examples/thoughts/package-lock.json

@infomiho you tested all these apps with the new Prisma? They all work fine?

Yep, all the apps were tested and they worked fine. The v5 major version was more about the new JSON protocol than anything, so nothing broke in our apps really :)

Martinsos · 2024-08-29T15:23:54Z

waspc/cli/exe/Main.hs

@@ -143,11 +143,7 @@ setDefaultCliEnvVars = do
  where
    cliEnvVars :: [(String, String)]
    cliEnvVars =
-      [ ("PRISMA_HIDE_UPDATE_MESSAGE", "true"),
-        -- NOTE: We were getting errors from Prisma v4 related to their Checkpoint system


Martinsos · 2024-08-29T15:29:18Z

waspc/src/Wasp/Generator/DbGenerator.hs

+-- | One of the checks we perform is to compare the Wasp generated schema.prisma file
+-- and the schema.prisma file in the node_modules. Prisma formats the schema in node_modules
+-- automatically, so we have to do the same to be able to compare them.
+formatPrismaSchemaFileOnDisk :: Path' Abs (Dir ProjectRootDir) -> IO ()


How is it that this is new?

I wasn't precise enough

This is new:

Prisma formats the schema in node_modules automatically

They didn't do that and we could do our diff check without formatting our output.

Makes sense. One question: How come we aren't comparing the ASTs? Seems more robust.

I'm guessing it was probably too much work for too litle gain.

We are in the business of comparing checksums like in all other places in the Wasp compiler :) that's why the source files needed to be the same.

infomiho · 2024-09-02T14:06:23Z

I assume you did a "diff" between the Prisma version we were on and Prisma 5, by checking their Changelog

According to their migration guide to v5: min. version of Node.js, Typescript and PostgreSQL changes, rejectOnNotFound was removed (we didn't use it) and some other stuff: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-5#removal-of-array-shortcuts%23removal-of-runtimeindexjs-from-generated-client

But nothing that major. I'll go over the release notes to see if I missed something 👍

is there anything new we should be adding support for in Wasp, or taht significantly changed?

There are new things, yes! I'm excited for their join support which would optimise some of our auth DB code - but I wouldn't really do it in this PR. I'll create an issue for that.

Seems from this PR that not much changed on the API level?

Yep, they kept things pretty much the same - which is great for us and our users :)

Martinsos · 2024-09-03T11:01:26Z

is there anything new we should be adding support for in Wasp, or taht significantly changed?

Awesome! Here I was asking more in the direction of, did they add something that we need to put extra effort to enable people to use it, becaues Wasp somehow doesn't allow it? But it sounds like there is nothing like that, at least nothing major.

sodic

Looks great!

Please just augment that comment and merge when ready.

sodic · 2024-09-02T15:02:45Z

waspc/data/Generator/templates/sdk/wasp/auth/lucia.ts

@@ -5,11 +5,8 @@ import { prisma } from 'wasp/server'
 import { type {= userEntityUpper =} } from "wasp/entities"

 const prismaAdapter = new PrismaAdapter(
-  // Using `as any` here since Lucia's model types are not compatible with Prisma 4
-  // model types. This is a temporary workaround until we migrate to Prisma 5.
-  // This **works** in runtime, but Typescript complains about it.


Always love seeing these kind of changes!

sodic · 2024-09-02T15:03:53Z

waspc/data/Generator/templates/sdk/wasp/server/crud/_operationTypes.ts

@@ -91,7 +91,10 @@ export type GetQueryResolved = typeof _waspGetQuery

 {=# crud.operations.Create =}
 {=^ overrides.Create.isDefined =}
-type CreateInput = Prisma.{= crud.entityUpper =}CreateInput
+type CreateInput = Prisma.XOR<


I trust this is correct, but can you give more details?

Asking just out of curiosity.

sodic · 2024-09-02T15:06:46Z

waspc/examples/todoApp/src/testTypes/operations/server.ts

  >,
-  // TODO: (FILIP) Prisma errors casuing this test to fail, try to add Except
-  // after updating Prisma: https://github.com/wasp-lang/wasp/issues/2099


Nice! Glad to see this is working now.

sodic · 2024-09-03T10:56:34Z

waspc/data/Generator/templates/sdk/wasp/prisma-runtime-library.d.ts

@@ -0,0 +1,14 @@
+// Without this import, Prisma types are resolved incorrectly.


The code comment doesn't fully explain what's happening and what the tradeoffs are. Do you mind adding this playground link too.

It currently implies that type types have an implicit index signature (which isn't really true, they only exhibit special subtyping behavior). The comment also doesn't mention the compromise we made by declaring an extension to the FieldRef interface.

Anyway, both things should be clear from the playground, and you can adjust it as you see fit.

BTW, what happend with trying to fix the root of the problem, the definition of the JSONSerializable type (as attempted here). Did Superjson make it too complex?

sodic · 2024-09-03T11:00:30Z

waspc/src/Wasp/Generator/DbGenerator.hs

+-- | One of the checks we perform is to compare the Wasp generated schema.prisma file
+-- and the schema.prisma file in the node_modules. Prisma formats the schema in node_modules
+-- automatically, so we have to do the same to be able to compare them.
+formatPrismaSchemaFileOnDisk :: Path' Abs (Dir ProjectRootDir) -> IO ()


Makes sense. One question: How come we aren't comparing the ASTs? Seems more robust.

I'm guessing it was probably too much work for too litle gain.

Signed-off-by: Mihovil Ilakovac <[email protected]>

infomiho added 5 commits August 8, 2024 13:45

Update Prisma to v5

bc64a24

Update --no-hints usage

e64a137

Merge branch 'main' into miho-prisma-5

580206d

Format generated Prisma schema

791b9aa

Fixes CRUD operation Prisma types

fd32b88

infomiho commented Aug 14, 2024

View reviewed changes

Cleanup

358d094

infomiho commented Aug 14, 2024

View reviewed changes

infomiho added 2 commits August 14, 2024 13:39

Cleanup

73f9b9d

Update e2e tests

83426ba

infomiho marked this pull request as ready for review August 14, 2024 11:44

Update package-lock.json files. Fixes todo-typescript example.

3dabf1b

infomiho commented Aug 14, 2024

View reviewed changes

Update package-lock.json

7ddd6a7

Signed-off-by: Mihovil Ilakovac <[email protected]>

infomiho force-pushed the miho-prisma-5 branch 2 times, most recently from 70656ad to 7ddd6a7 Compare August 20, 2024 15:39

Merge branch 'main' into miho-prisma-5

046e6af

infomiho requested a review from sodic August 22, 2024 14:16

infomiho added 2 commits August 22, 2024 16:51

Update example apps

7a7d17a

Merge branch 'main' into miho-prisma-5

6e219aa

Martinsos reviewed Aug 29, 2024

View reviewed changes

Merge branch 'main' into miho-prisma-5

7383a72

sodic approved these changes Sep 3, 2024

View reviewed changes

Update comment

65b31df

Update Prisma to 5.19.1

f3864d2

infomiho force-pushed the miho-prisma-5 branch from 1584326 to f3864d2 Compare September 4, 2024 12:09

infomiho added 3 commits September 4, 2024 14:14

Update e2e tests

9654b9c

Update thoughts package-lock.json

ae3bf9a

Signed-off-by: Mihovil Ilakovac <[email protected]>

Update headless-test package-lock.json

e58fdde

infomiho merged commit ac38c6a into main Sep 4, 2024
6 checks passed

infomiho deleted the miho-prisma-5 branch September 4, 2024 13:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Prisma to v5 #2231

Update Prisma to v5 #2231

infomiho commented Aug 8, 2024 •

edited

Loading

infomiho Aug 14, 2024

infomiho Aug 14, 2024

sodic Sep 3, 2024

infomiho Sep 4, 2024

infomiho Aug 14, 2024

sodic Sep 2, 2024

infomiho Sep 4, 2024 •

edited

Loading

infomiho Aug 14, 2024 •

edited

Loading

infomiho Aug 14, 2024

infomiho Aug 14, 2024

infomiho Aug 14, 2024

Martinsos left a comment

Martinsos Aug 29, 2024

infomiho Sep 2, 2024

Martinsos Aug 29, 2024

Martinsos Aug 29, 2024

infomiho Sep 2, 2024

sodic Sep 3, 2024

infomiho Sep 4, 2024

infomiho commented Sep 2, 2024

Martinsos commented Sep 3, 2024

sodic left a comment

sodic Sep 2, 2024

sodic Sep 2, 2024

sodic Sep 2, 2024

sodic Sep 3, 2024

sodic Sep 3, 2024

		@@ -0,0 +1,14 @@
		// Without this import, Prisma types are resolved incorrectly.

Update Prisma to v5 #2231

Update Prisma to v5 #2231

Conversation

infomiho commented Aug 8, 2024 • edited Loading

Left to do

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho Sep 4, 2024 • edited Loading

Choose a reason for hiding this comment

infomiho Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Martinsos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho commented Sep 2, 2024

Martinsos commented Sep 3, 2024

sodic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho commented Aug 8, 2024 •

edited

Loading

infomiho Sep 4, 2024 •

edited

Loading

infomiho Aug 14, 2024 •

edited

Loading