Certain model names cause clashes in generated types
#12469
Comments
Jolg42
added
bug/1-unconfirmed
pantharshit00
added
bug/2-confirmed
|
|
|
Just got hit with this by migrating prisma from Renaming the model worked for me but is there another workaround besides that? |
If I remember correctly, I had to disable |
Yes, that works as well. But i prefer model rename over this in order not to compromise type safety. |
|
@janpio - Just ran into this with our Batch model, which is clobbered by the BatchPayload type (we basically can't validate any Batch items). This is really frustrating because we only just now started to need to control the return type for Batch, and we can't because of the overriding BatchPayload type, but this model is already all over our codebase. Even worse - I read on this issue that the Metric model (which, honestly, we're using a whole lot more and have had already for months) is similarly impacted - and the only reason we haven't noticed is because we already made ourselves a derived type for Metric and don't refer to the Metric model type directly anywhere, purely by accident. We're going to go through everything and rename both our Batch and Metric models, but - this list here should really, really be in your documentation. It's crazy that it took adding a relationship to a model to discover that we were messing with Prisma internals, and crazier that this is the only place I could find any discussion on the topic. And frankly, Prisma should stop you from generating models if you try to clobber one of these types. It shouldn't even let me create a Metric or a Batch model if this is what's going to happen. I understand you see this as a "temporary limitation" but it's a real limitation that's going to be with us for the foreseeable future - you have a huge roadmap and I just know this is not at the top of the list. Better to warn people than to pretend it's not there. |
Problem: even though built-in `Metric` type is placed in a different namespace, type conflict still occurs: `Delegate` classes are in the same namespace and can't refer to non-namespaced name. Implements a tiny part of [namespace overhaul proposal](https://www.notion.so/prismaio/Fix-type-name-clashes-in-TS-Client-9e9bbdee13f94a818ece060e55465267): introduces `$Models` namespace. Ref #12469
Problem: even though built-in `Metric` type is placed in a different namespace, type conflict still occurs: `Delegate` classes are in the same namespace and can't refer to non-namespaced name. Implements a tiny part of [namespace overhaul proposal](https://www.notion.so/prismaio/Fix-type-name-clashes-in-TS-Client-9e9bbdee13f94a818ece060e55465267): introduces `$Models` namespace. Ref #12469
After looking through the issues, we had a couple of more clashes that needed additional work: 1. `Check` and `Has` collide with built-in `CheckSelect`/`HasSelect` types. Those types are not public and not used since prisma 4.16.0, so I just removed them from generated file. 2. `Promise` is more complicated and required aliasing built-in type. Fix #17542 Fix #9669 Close #12469
…#20215) * fix(client): Allow to use `Check`, `Has` and `Promise` as model names After looking through the issues, we had a couple of more clashes that needed additional work: 1. `Check` and `Has` collide with built-in `CheckSelect`/`HasSelect` types. Those types are not public and not used since prisma 4.16.0, so I just removed them from generated file. 2. `Promise` is more complicated and required aliasing built-in type. Fix #17542 Fix #9669 Close #12469 * Ensure type alias is still displayed as `Promise` in editor * Try different method --------- Co-authored-by: Joël Galeran <Jolg42@users.noreply.github.com>
|
All of those conflicts are fixed and all mentioned names should be useable as model name starting with upcoming Prisma 5.1 release. |
Bug description
The following are all exported types from the
index.d.tsand will cause clashes if they have correspondingmodelsin the Prisma schema.How to reproduce
Expected behavior
No response
Prisma information
n/a
Environment & setup
Prisma Version
Existing related issues
Datasourcebreaks generated return types #12332ModelandModelUpdateis defined in the schema #9568, Incorrect Include typings when having models calledXandXUpdate#7518The text was updated successfully, but these errors were encountered: