Feature: Prisma GraphQL with import

[rodrigooler]

The idea would be to copy the way @prisma/client deals to avoid importing files generated through the plugin.

We can leave the files inside a .gitignore to avoid uploading a lot of unnecessary code and calling a module that solves this import.

Example

import {User} from '@ nestjs/prisma-graphql'

@Mutation (() => User)
async user () {}

or

import {UserGraphQL} from '@prisma/client'

@Mutation (() => UserGraphQL)
async user () {}

Rather than

import {User} from '../../../prisma/user/user.model'

@Mutation (() => User)
async user () {}

@unlight

[unlight]

I'm not sure that I got your idea clearly... do you want to import all possible classes from single module entry, same as requested here #6?

If yes you can use setting reExportAll and typescript's tsconfig#paths feature.
But I do not recommend such way, the explanation is here #5

[felinto-dev]

In the schema.prisma file you can define where the files generated by the plugin will be saved, ok?

https://github.com/unlight/prisma-nestjs-graphql/blob/master/prisma/schema.prisma#L13

In this case, the idea would be to point to the node_modules folder of the plugin so that it was possible to do this, in the same way, that @prisma/client does:

import {User} from 'prisma-nestjs-graphql/models/user.ts'

@Mutation (() => User)
async user () {}

But to make this implementation, it is necessary to create an index.d.ts file that points to the @generated folder in the same way @prisma/client does.

PS: It is strange that @prisma/client does not need an "output" argument. I believe that the "provider" can specify a default value as well. If I followed this line of reasoning, I believe that it would not be necessary to inform the output, although I still find it interesting to have the option of defining it manually and overriding the standard.

[felinto-dev]

I realize @unlight, you put the label "need-clarification". What did you don't understand exactly?

[unlight]

@felinto-dev

I did not understand why combination of existing solutions with tsconfig#paths and option reexport does not work for you.
Also, there are new options emitSingle and emitCompiled where you can achieve almost same results.
output option controls target output directory, you can point it to anywhere including node_modules

[felinto-dev]

@felinto-dev

I did not understand why combination of existing solutions with tsconfig#paths and option reexport does not work for you.
Also, there are new options emitSingle and emitCompiled where you can achieve almost same results.
output option controls target output directory, you can point it to anywhere including node_modules

I didn't know I had these options or how to implement them in my specific use case.

Thanks for the feedback. I will check the documentation and apply them accordingly!