Type name clash when Model and ModelUpdate is defined in the schema

[pantharshit00]

Bug description

Prior context: #9421

We are encountering a conflict in our generated typing when a model named User for example is defined along with UserUpdate, it will generate invalid type that won't compile.

How to reproduce

Generate client with the following model:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}


model User {
  id String @id @default(cuid())
}

model UserUpdate {
  id String @id @default(cuid())
}

Expected behavior

Client should generate valid types for any valid schema

Prisma information

See above in "how to reproduce"

Environment & setup

• OS: Windows 10
• Database: Postgres
• Node.js version: 14.17.0

Prisma Version

Environment variables loaded from prisma\.env
prisma                  : 3.2.0-dev.48
@prisma/client          : 3.2.0-dev.48
Current platform        : windows
Query Engine (Node-API) : libquery-engine a153cf0caf0e5e24b69198dcdc040568256a1124 (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli a153cf0caf0e5e24b69198dcdc040568256a1124 (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core a153cf0caf0e5e24b69198dcdc040568256a1124 (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt a153cf0caf0e5e24b69198dcdc040568256a1124 (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : a153cf0caf0e5e24b69198dcdc040568256a1124
Studio                  : 0.435.0

[andrewpap22]

Any news on this?

We're getting with @Learus the same error, when trying to build for production, while on dev environment everything seems to be working properly.

The error:

#0 63.80 ../node_modules/.prisma/client/index.d.ts:10331:62
#0 63.80 Type error: Type 'S["include"][P]' does not satisfy the constraint 'boolean | AccountssArgs | null | undefined'.
#0 63.80   Type 'S["include"]["created_by_account"]' is not assignable to type 'boolean | AccountssArgs | null | undefined'.
#0 63.80     Type 'S["include"]["created_by_account"]' is not assignable to type 'boolean | AccountssArgs | null | undefined'.
#0 63.80       Type 'S["include"]["created_by_account"]' is not assignable to type 'AccountssArgs'.
#0 63.80         Type 'S["include"]["created_by_account"]' is not assignable to type 'AccountssArgs'.
#0 63.80           Type 'S["include"][P]' is not assignable to type 'AccountssArgs'.
#0 63.80             Type 'S["include"]["created_by_account"]' is not assignable to type 'AccountssArgs'.
#0 63.80               Type 'S["include"]["created_by_account"]' is not assignable to type 'AccountssArgs'.
#0 63.80
#0 63.80   10329 |     ? Accountss  & {
#0 63.80   10330 |     [P in TrueKeys<S['include']>]:
#0 63.80 > 10331 |         P extends 'created_by_account' ? AccountssGetPayload<S['include'][P]> :
#0 63.80         |                                                              ^
#0 63.80   10332 |         P extends 'modified_by_account' ? AccountssGetPayload<S['include'][P]> :
#0 63.80   10333 |         P extends 'account_is_personel' ? personel_employeesGetPayload<S['include'][P]> | null :
#0 63.80   10334 |         P extends 'students' ? studentsGetPayload<S['include'][P]> | null :
#0 63.93
#0 63.93 > Build error occurred

The "solution" mentioned in #9421 of renaming model fooUpdate when having another model foo in the schema did not resolve the error for me.

Environment & Setup

• OS: Artix Linux
• Database: MariaDB
• Node.js version: v14.20.0
• Typescript version: 4.8.2

Prisma Version

prisma                  : 3.10.0
@prisma/client          : 3.10.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : 73e60b76d394f8d37d8ebd1f8918c79029f0db86
Studio                  : 0.458.0
Preview Features        : interactiveTransactions, filterJson

[CanTheAlmighty]

I ran into the same issue today with Typescript 4.9 and Prisma 4.6.1 (In fact, I actually upgraded everything hoping it would fix itself).

The errors:

node_modules/.prisma/client/index.d.ts(25062,64): error TS2344: Type 'T' does not satisfy the constraint 'boolean | EventPostUpdateArgs | null | undefined'.
  Type 'EventPostUpdateFindUniqueArgsBase' is not assignable to type 'boolean | EventPostUpdateArgs | null | undefined'.
    Type 'EventPostUpdateFindUniqueArgsBase' is not assignable to type 'EventPostUpdateArgs'.
      Type 'T' is not assignable to type 'EventPostUpdateArgs'.

Renaming the models from FooUpdate to FooChanges fixed the issue instantly, but it required an insane amount of google-fu to reach this issue.

Edit

Taking a peek at the file generated, it would seem that the generated typescript file heavily relies on the word Update. For example, I have an object named Board, and these are the results of compilation:

...
export type BoardUpdateArgs = { ... }
...
export type BoardArgs = { ... }

So the problem exists when you have Object and ObjectUpdate as it will attempt to create as such:

Object
  -> ObjectArgs
  -> ObjectUpdateArgs**
ObjectUpdate
  -> ObjectUpdateArgs**
  -> ObjectUpdateUpdateArgs

[CanTheAlmighty]

I just found out today that it also happens when properties are also named update or updates, again, renamed "update" to "props" has circumvented the issue.

[SevInf]

This issue is now fixed and the fix will be published as a part of 5.1 release. If you'd like to verify fix earlier, you can use dev snapshot 5.1.0-dev.24. We don't recommend using it in production, but it should be enough to verify the fix.