-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Type name clash when Model
and ModelUpdate
is defined in the schema
#9568
Comments
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 Environment & Setup
Prisma Versionprisma : 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 |
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:
Renaming the models from EditTaking a peek at the file generated, it would seem that the generated typescript file heavily relies on the word
So the problem exists when you have
|
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. |
In some cases, generated types for one of the models will clash with generated types for another. In that case, we would generate duplicate type. This PR fixes this: approach is very different to namespaces proposal I shared earlier. Turns out, most of the conflicts are solved by just renaming default args types from `ModelArgs` to `ModelDefaultArgs`. Deperecated alias for an old name would still be created if it does not conflict. Somewhat different case is `Payload` type. First, they are created at top level of the file, rather then in `Prisma` namespace. @millsp and I agreed that thouse types are not public, so it is safe to move them to namespace and rename them. So, `UserPayload` would now become `Prisma.$UserPayload`. This allows to both use `UserPayload` as a model name as well as use `Batch` as a model name (we have built-in `BatchPayload` type that is unrelated to aforementioned `Payload` types). Fix #19967 Fix #18902 Fix #16940 Fix #9568 Fix #7518
In some cases, generated types for one of the models will clash with generated types for another. In that case, we would generate duplicate type. This PR fixes this: approach is very different to namespaces proposal I shared earlier. Turns out, most of the conflicts are solved by just renaming default args types from `ModelArgs` to `ModelDefaultArgs`. Deperecated alias for an old name would still be created if it does not conflict. Somewhat different case is `Payload` type. First, they are created at top level of the file, rather then in `Prisma` namespace. @millsp and I agreed that thouse types are not public, so it is safe to move them to namespace and rename them. So, `UserPayload` would now become `Prisma.$UserPayload`. This allows to both use `UserPayload` as a model name as well as use `Batch` as a model name (we have built-in `BatchPayload` type that is unrelated to aforementioned `Payload` types). Fix #19967 Fix #18902 Fix #16940 Fix #9568 Fix #7518
In some cases, generated types for one of the models will clash with generated types for another. In that case, we would generate duplicate type. This PR fixes this: approach is very different to namespaces proposal I shared earlier. Turns out, most of the conflicts are solved by just renaming default args types from `ModelArgs` to `ModelDefaultArgs`. Deperecated alias for an old name would still be created if it does not conflict. Somewhat different case is `Payload` type. First, they are created at top level of the file, rather then in `Prisma` namespace. @millsp and I agreed that thouse types are not public, so it is safe to move them to namespace and rename them. So, `UserPayload` would now become `Prisma.$UserPayload`. This allows to both use `UserPayload` as a model name as well as use `Batch` as a model name (we have built-in `BatchPayload` type that is unrelated to aforementioned `Payload` types). Fix #19967 Fix #18902 Fix #16940 Fix #9568 Fix #7518
In some cases, generated types for one of the models will clash with generated types for another. In that case, we would generate duplicate type. This PR fixes this: approach is very different to namespaces proposal I shared earlier. Turns out, most of the conflicts are solved by just renaming default args types from `ModelArgs` to `ModelDefaultArgs`. Deperecated alias for an old name would still be created if it does not conflict. Somewhat different case is `Payload` type. First, they are created at top level of the file, rather then in `Prisma` namespace. @millsp and I agreed that thouse types are not public, so it is safe to move them to namespace and rename them. So, `UserPayload` would now become `Prisma.$UserPayload`. This allows to both use `UserPayload` as a model name as well as use `Batch` as a model name (we have built-in `BatchPayload` type that is unrelated to aforementioned `Payload` types). Fix #19967 Fix #18902 Fix #16940 Fix #9568 Fix #7518
This issue is now fixed and the fix will be published as a part of |
Bug description
Prior context: #9421
We are encountering a conflict in our generated typing when a model named
User
for example is defined along withUserUpdate
, it will generate invalid type that won't compile.How to reproduce
Generate client with the following model:
Expected behavior
Client should generate valid types for any valid schema
Prisma information
See above in "how to reproduce"
Environment & setup
Prisma Version
The text was updated successfully, but these errors were encountered: