Prisma generators output abnormally - A bug, or a possible source of confusion

Issue:

When executing the npx prisma generate command, there is a possibility of an error with the following log or a similar error message:

"'node_modules/@prisma/client' has no exported member 'PrismaClient'." 

Bug description

In such a situation, none of the auto-generated types, interfaces, classes, or simply PrismaClient itself can be loaded from its intended place which happens to be @prisma/client.

For example, the following will fail with similar error as the above, or IDE(s) will decorate the import with a red underline flag.

generator client {
  provider      = "prisma-client-js"
  // output <-- if not provided, it should default to `node_modules/@prisma/client`
}

Problem(s):

A: The npx prisma generated command is widely used on prisma.io as well as many 3rd-party blogs all over the internet. That command “seems” to be installing prisma on its first ever run, however, thereafter, using the cached version only, unless a newer version is available. If so, as long as the end-users stick with running npx prisma generated they “seem” be fine.

However, if for whatever reasons, they decided to run the generate command differently, they might run into the above problem.

Example:

    "prisma:generate": "node ./node_modules/.bin/prisma generate --schema=<some-path>/prisma/schema.prisma"

Solution A: Ensure the installed version of prisma is removed from yarn &| npm globally, prior to running the command specifically.

This is, to ensure that your prisma command and the designated output path, both point to the same instance of prisma. Otherwise, your command stores the output of generated files at location (a), while your IDE/build is point to location (b).

B: Furthermore, to ensure the “no stone unturned” policy during my research, a second instance of the generator was introduced to the config file.

generator client {
  provider      = "prisma-client-js"
  // output <-- if not provided, it should default to `node_modules/@prisma/client`
}

generator dbml {
  provider = "prisma-dbml-generator"
  output   = "./generated/dbml" // this seems to overwrite the output of the default generator above
}

At this point, even if the output is set in the configuration for the first generator, it becomes redundant, and the second output “seems” to win all the time, or simply things get really messed up.

Solution B: 1 - Repeat solution (A) 2 - mv node_modules /tmp // hint: you can also rm -rf node_modules, but mv is snappier 3 - yarn install | npm install 4 - run your generate command:

• don’t use both npx generate and "prisma:generate": "node ./node_modules/.bin/prisma generate interchangeably

Ok, I am leaving the research at the above combinations/permutations, and passing this to the capable hands of Prisma staff.

How to reproduce

1 - run npx generate of your prisma-aware project 2 - include import { PrismaClient } from '@prisma/client' 3 - ensure both of your IDE & build are happy with line 2 4 - add the next line to your script section of your packages.json

• "prisma:generate": "node ./node_modules/.bin/prisma generate --schema=<some-path>/prisma/schema.prisma"
• make sure prisma is found in your package.json
• ensure <some-path> is replaced with the actual path where schema.prisma is found

5 - run yarn prisma:generate or npm run prisma:generate 6 - refresh / reload your IDE (vscode, etc) 7 - verify that your IDE is unhappy with your import in step 2 8 - continue with solution A, from above and repeat step 6-7 8 - (optional) advanced steps from line 9 … 9 - add another generator as per the above (B) example, or any other generator 10 - repeat step 6-7 to verify

Expected behavior

1 - To have used version 2 of prisma by installing the software & its modules from @prisma/* namespace ONLY.

TL&DR: (personal experience only - no rants) prisma was the namespace for version of the software which has been left behind, in favor of prisma 2 which occupies the @prisma/* namespace. It would have been very natural, to have left the old namespace alone and utilize the new namespace moving forward. Recycling of the old namespace like, “old cli was there, now it’s here, but you could have used it in prisma, but @prisma/cli is there too, which is not used, but may be used … etc.” did create a massive amount of confusion for me, as per my research from the issues section of this repo, stackoverflow questions, online youtubes etc.

2 - To have the ability to look at one place for all the generated artifacts, whether using a custom path or the default path at @prisma/client

3 - To have the output of each generator section bound to that generator only.

Prisma information

Default schema from the user:post examples on prisma.io

Exception:

generator dbml {
  provider = "prisma-dbml-generator"
  output   = "./generated/dbml"
}

Default client queries from the user:post examples on prisma.io

Environment & setup

prisma               : 2.20.1
@prisma/client       : 2.20.1
Current platform     : darwin
Query Engine         : query-engine 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt 60ba6551f29b17d7d6ce479e5733c70d9c00860e (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : 60ba6551f29b17d7d6ce479e5733c70d9c00860e
Studio               : 0.365.0
--- optional ---
Nrwl / Nx env. 

Finally

The mileage on the above research varies, and it would require way more combo/permu to fully test and understand the current behavior, so please take my findings with a grain of salt, as I have not tested this on Linux/Windows and other version of the product. Also: the context of my research is only bound to the aforementioned versions from the Env/Setup section.

Link and references

https://github.com/prisma/prisma/issues/2584#issuecomment-812261556

[un33k]

@pantharshit00 I cleaned up the global version and forced everything point to the local version. I am not seeing the problem anymore, mind you I don’t use npx anymore and sadly I didn’t get the version of the global prisma.

[leppaott]

We’ve run npm install on monorepo recursive for each service and it end up with this. Might this be related