prisma: Code completion / auto imports / CTRL clicking to props breaks in .beta 4 for webstorm

A workaround is edit your prisma.schema file so it outputs client in your home directory:

generator client {
 provider = "prisma-client-js"
 output   = "./prisma/client"
}

Then run npx prisma generate

I started with prisma yesterday and this was the most frustrating thing.

Update: The other option is to right click on the .prisma folder -> Mark Directory as -> Cancel Exclusion

The issue in webstorm has graduated - upvote for it to get some attention 😃

https://youtrack.jetbrains.com/issue/WEB-45487

I also have a request in with Jetbrains support to try and help isolate this. In my mind, it should be working so there may be an option that needs tweaking within the IDE. You’re re-exporting all of .prisma/client from @prisma/client so not sure why it doesn’t pass through.

Folks might already know this, but…

I believe the underlying issue here that WebStorm only indexes packages that are being depended on for projects as told by the package.json and respective lock; this is an optimisation feature because one of the underlying core features of JetBrains IDEs is that they maintain a built-in index of whole projects, which has a costly initial build/startup time but afterwards makes it really fast (in theory at least).

So because .prisma is not a dependency as per the package.json, WebStorm doesn’t like trying to look into it - you can confirm this by sticking ".prisma": "1" in your package.json after which WebStorm should magically start working; however this of course is not a workable solution since package managers will have no idea what to do about that and so error.

This is similarly why “Mark as unexclude” works (note that it has to be applied to the client folder, not .prisma) - the problem with this is that now WebStorm will think it’s part of the project and so will include it when doing searches and other such things.

The result is that WebStorm cannot use its features for autocompletion, type handling, definition lookup, etc, and instead has to fallback to using the more basic information that the TypeScript language server provides (which is both slow and much more limited).

However if the client is generated in an actual dependency (say… @prisma/client), WebStorm will be completely happy with that; currently I’ve got my output set to "../node_modules/@prisma/client/generated" and am importing from @prisma/client/generated with a very happy WebStorm.

This could be resolved on the prisma end if the default generated output (and re-export path used by @prisma/client\index.d.ts) was moved to be within the @prisma/client package:

export * from './.prisma/client'

IMO this should be a relatively safe change because the fact that @prisma/client has the re-export means it already knows about the path, so there shouldn’t be any “what is @prisma/client doesn’t exist, changes its name, etc?”.

My ridiculous “workaround” is to switch to VSCode when calling prisma… where everything works as expected, but a few things are really inferior, if you get used to WebStorm. Unfortunately Webstorm sometimes seems to be a low prio for JetBrains. And: Prisma is IMHO not just “any other library” in the ecosystem.

There are now a plugin developed by Jetbrains that works perfect.

https://plugins.jetbrains.com/plugin/20686-prisma-orm

Edit: The described workaround does not work (for us), when using db.$transaction. There’s no code completion in Webstorm within the transaction.

You can also try removing node_modules/.prisma from indexing exclusion list in webstorm.

Is there any progress on this issue?

I was using a workaround like this for Prisma + Next.js (or rather Prisma + Blitz.js in my case, but that’s not relevant).

So my code (before) looked like this:

import { PrismaClient } from "@prisma/client";

declare global {
  var prisma: PrismaClient | undefined;
}

export const prisma =
  global.prisma ||
  new PrismaClient({
    log: ["query"],
  });

if (process.env.NODE_ENV !== "production") global.prisma = prisma;

and now looks like this:

import { Prisma, PrismaClient } from "@prisma/client";

type HotReloadablePrismaClient = PrismaClient<
  Prisma.PrismaClientOptions,
  never,
  Prisma.RejectOnNotFound | Prisma.RejectPerOperation | undefined
>;

declare global {
  var prisma: HotReloadablePrismaClient;
}

export const prisma: HotReloadablePrismaClient =
  global.prisma ||
  new PrismaClient({
    log: ["query"],
  });

if (process.env.NODE_ENV !== "production") global.prisma = prisma;

This is the same setup for my Blitz app:

import { enhancePrisma } from "blitz";

const EnhancedPrisma = enhancePrisma(PrismaClient);

const enhancedPrisma: PrismaClient<
  Prisma.PrismaClientOptions,
  never,
  Prisma.RejectOnNotFound | Prisma.RejectPerOperation | undefined
> = new EnhancedPrisma();

export default enhancedPrisma;

This is admittedly still a bit laggy or slow if you type faster than it resolves the types… which is probably due to the reasons explained perfectly by @G-Rath, that .prisma is not indexed by WebStorm properly, and it’s probably

using the more basic information that the TypeScript language server provides (which is both slow and much more limited).

https://user-images.githubusercontent.com/32647249/140777585-20cebec2-4b77-4db4-817e-9e8f827813de.mov

Combining it with the solution suggested by @G-Rath, i.e. generating prisma-client into a directory indexed by Webstorm, e.g. node_modules/@prisma/client/generated or just a local ./my-prisma-client-dir makes it superfast in my case, though.

https://user-images.githubusercontent.com/32647249/140781695-869d27b1-8811-4e89-bd1d-2c02509aaac7.mov

@Evilweed, you could check whether at least the plain Prisma setup at https://www.prisma.io/docs/getting-started/quickstart works with your Webstorm, because that worked for me and then (if that works) triage, what makes your current setup different.

Sadly all suggested workarounds do not work for me.

@ahsane I had to log in just to say: “Thank you!” The workaround worked!

Thanks @webnoob, persisted at https://github.com/prisma/prisma-examples/issues/1765

@janpio Sorry I was in a rush and forgot to create a new issue for it. It’s here: https://www.prisma.io/docs/getting-started/quickstart-typescript#download-sqlite-starter-project--install-dependencies

I used the windows version so haven’t tested the linux variation.