Large schemas generate huge `index.d.ts` causing slow autocomplete and type-checking in your editor

[andrehsu]

Problem

Whenever I generate the prisma client again after modifying the schema, it takes a while for WebStorm (an IntelliJ-based IDE) to reflect the changes in static analysis. While I haven't done any benchmarking to confirm this is the case, I think it is because
of the thousand lines long index.d.ts. Seeing as the draw of Prisma is that it is typed, I feel like an improvement in the static analysis performance would be relevant to the project.

Suggested solution

Split the index.d.ts file into separate type-def files for potentially faster static analysis.

[matthewmueller]

Hey @andrehsu! Thanks for raising this issue.

We have started thinking of ways to first measure our Typescript type-check performance, but so far it hasn't been prioritized.

Ideas for next steps:

1. Feel the pain. A video demonstrating the slowness in your IDE would be very helpful for us.
2. Figure out a solution (maybe split files, reduce type generation, etc.). One thing to try would be to break out the types into separate files and link them up by hand. If it proves to be a lot faster, that tells us this change is worth doing.

Any help with 1. and/or 2. would accelerate fixing this problem.

[MattGson]

@matthewmueller I have a slightly stronger use case for this. Our prisma index.d.ts file is over 400,000 lines long. At this size, Webstorm and VSCode both stop linting entirely and many other related functions stop working such as auto-completion on types. A sensible solution would probably be to split the types up into one file per table. From my experience, both IDEs can easily handle hundreds of files well but cannot handle very long files.

[mribichich]

I have another use case, similar to frontend projects.

I've been trying to use prisma client in our BE project, but people are still reluctant to use it, so we've been only using the types and enums from prisma.

The thing is since we use webpack, and all the prisma types and enums are in the same file as the client, even if you dont use the client, webpack bundles everything from the file (node_modules/.prisma/client/index.js).

So having 3 separate files would solve everyone's problem:

• one file for the client implementation
• one/multiple files for the types (it could also have a index to re-export them all)
• one file for the enums

It seems to be a fairly easy change to make, without any functionality change. it's just a file organization.

Also for the prisma client files, tree shacking doesn't work. So even if you import one enum you get everything.

Even putting the dmmfString const would reduce 1.5MB from the import.

[seamory]

I have the same question. static analysis use a lot of memory but not have any result, becase of the tens of thousands of lines in index.d.ts.

[maximkott]

A slightly different use case here: I wan't to build and bundle my app into *.js and *.d.ts files and I want my models to be part of it, without any notion of prisma. Simply re-exporting my models will not work, since prisma is treated as an external module. Forcing typescript to include prisma models into the build, leads to compilation of tens of thousands of lines of code/types that are not necessary. This happens simply because models and other prisma types are in the same file. Besides that, I was not able to get the build working because something always causes an error within prisma files.

I don't see an easy workaround for this as of yet. The current setup is really limiting, unfortunately. All I want is to include those 200 lines of types without being forced to process additional 30k lines that never tend to compile.

This is the only issue I have with Prisma so far, it's really awesome otherwise! 😃

[maximkott]

My current workaround is to copy & paste models from prisma (they are almost at the top of node_modules/.prisma/client/index.d.ts) to a file called models.ts. Then I make sure that I import all my model types from the models.ts file, rather than from @prisma/client directly. The downside is that you have to copy & paste those models again after every schema change 😆

Maybe this helps someone.

[seamory]

Hello, i found the cause why webstorm or idea spend to much time to analyse, but no result. you need to symbol the path .\node_modules.prisma with your project as resources or sources in Project structure in Modules in Project Setting Tab.

As follow pic.

Hope it's helpful.

[michael-land]

It would be nice user can disable features to avoid generate unused types

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["nApi"]
  disableFeatures = ["filterJson", "orderByAggregateGroup"]
}