1. Why can't VScode/typescript not pull types directly from the schema without the need for this step?
   Or rather, why is the schema not a typescript file in the first place?

2. More importantly, I guess, I don't see these types being stored anywhere. If they reflect the schema 1-to-1, I feel they should also be checked into source control. But if they don't exist anywhere physically, or if they are stored in some kind of temp/cache folder that obviously is ignored, then they won't be in source control.

VSCode can't make up types from a schema file. Prisma generates types based on your schema, then VSCode reads them. They are typically stored in node_modules (depending on what package manager you use, usually in .prisma folder). You can personalise this behaviour by setting the output in your schema (https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/generating-prisma-client#the-location-of-prisma-client).

You can set the output to some folder within your project and commit the output to your source control if you wish to. However, I prefer not to commit those and just prisma generate during deployment.

Also, a prisma schema can't be a typscript file (check the generated types to know the amount of work needed), a schema will also generate JS files not just typescript.

And for VSCode, I think it doesn't quickly pickup the new types due to performance. VSCode can't just keep scanning all the time or your computer will choke. Sometimes you need to help VSCode parse again those types by cmd+click into @prisma/client and then cmd+click into .prisma which opens the generated types file and makes VSCode re-read the types.

Another way is to cmd+shit+P, then type Typescript Restart and select the first option to restart TS server of VSCode which will parse again all types.

If schema files were typescript, then javascript files (or rather, typescript files that aren't type declaration files) could still be generated.

The amount of types is the perfect reason to use typescript, not an excuse to generate it after the fact. It would also solve the problem of how one would derive UserCreateInput from the basic User interface. Currently there is absolutely no connection between the two.

I would much rather see a CreateInput<User>. This also makes it a billion times easier to deal with input and output from generated functions, in generics. This would make it easy, for example, to write a generic function that takes the input of T and know upfront what its output has to be.

No sorry mate, but typescript is absolutely perfect for this.

Thany, how would you define relations?

model User {
   somethingId String
   something @relation("SomeRelation", fields: [somethingId], references: [id])

How would you define extensions in the schema file?

generator { ... }
datasource {.... }

How would you add extensions to fields?

model Something {
   field String @default("hello") 

  @@map("collectionName")
}

How would you differentiate between a model and an embedded document?

model User {
  something EmbeddedDoc
}

type EmbeddedDoc {
  someEmbeddedData Int
}

How would you define the database type?

model Something {
  field1 Int (typescript is just number)
  field2 Float (typescript is number as well)
}

Please understand well Prisma before making such comments. The team is making great work and you'll need to understand fully how Prisma works before making such suggestions. Otherwise, just use other node libraries, there are many of them.

Go ahead and close it, but it was not actually answered. Just some talking down on me. This was just some experimentation for me, and so the project is no longer active. I might use it again some day.

Crazy how I'm having this problem years later, but seeing how this interaction went, I best go off and figure it myself.

Same Problem!

Thanks for the help, it worked.

that works out

This really helped after hours of searching. Thanks

I had a similar problem and it was resolved by

rm -rf node_modules rm -rf .next npm install npx prisma generate

I use Prisma version 7 and import Prisma generated client from prisma/generated folder. The error was:

The requested module './generated/client.ts' does not provide an export named 'PrismaClient' 

I tried this sequence of commands, and still had the same error. The error disappeared after I also removed prisma/generated folder. So in my case (Nuxt) it was following order:

1. rm -rf node_modules
2. rm -rf .nuxt
3. npm install
4. rm -rf prisma/generated
5. npx prisma generate

Personally, neither option suited me. I found a solution by upgrading to the prisma v6.0.0 version.

This really helped

This is not a recommended approach right?

Nice!

This cause many errors after running "npm run build" for me.
Then i revert it back to "@prisma/client". This gave not many but single error too.
Then I recheck my whole NextJS folder structure. Tried to organised them in recommended way.
"@prisma/client" still not worked.

Then I revert it back to "import {PrismaClient} from "@/generated/prisma";".
delete node_modules
delete .next
run npm install
run npx prisma generate

And finally "npm run build" worken without any error.

PS: I saw "@/generated/prisma" import is currently recommended way in time I have searched for solution.

be aware that in Prisma 7 specifying output will be required: https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/generating-prisma-client

Thank you. I will keep this in mind.

this way works fine for me, thanks a lot bro

Thanks a lot, you are a saviour. I still don't get it, why some code does import @prisma/client and that works, even I had done that in some of my projects and that worked fine, very strange.

Anyway thanks man

Thanks bro

Thanks buddy!! This worked.

Thanks, bro! But in my case "output" prop is not nessesary. If you don't specify this property, it will create the client at '@prisma/client', not in a separate folder in the root.

Thanks bro