search

graphql-nexus / nexus

Code-First, Type-Safe, GraphQL Schema Construction
https://nexusjs.org
MIT License
3.4k stars 274 forks source link

Multiple schemas typing issues #269

Open alizhdanov opened 4 years ago

alizhdanov commented 4 years ago

Hello, I have two schemas in one project (just for example - schema1 and schema2). Each of them has it's own nexus-typegen generated file. Types for schema1 are working fine, the issue with schema2. For instance when I wanna create new mutationField:

mutationField('createDoughnut', {
  type: 'Doughnut',
});

It'd show typescript error that type '"Doughnut"' is not assignable to type .... The issue that this type defined in schema2, but not in schema1. But types always checked from schema1.

The issue seems to be, because of nexus is dependant on global types defined in @types/nexus-typegen__nexus-core. 

declare global {
  interface NexusGen extends NexusGenTypes {}
}

In my case I generate, which mean that only one of the file will be applied:

Is it possible somehow to link types manually?

valentinpalkovic commented 4 years ago

Therefore it is currently also not usable with graphql-modules, if you have at least two nexus modules

tgriesser commented 4 years ago

The assumption of nexus is that there is one schema per typescript project. If you use a lerna/yarn workspaces style monorepo, it should work if you have the generated types emitted into separate projects. I currently use this approach with an "admin" schema which is a superset of the "public" schema. In order for this to work you need to manually specify the output paths for these modules.

I'm not sure about graphql-modules.

valentinpalkovic commented 4 years ago

@tgriesser Why is typescripts declaration merging not working? I do not get it exactly.

tgriesser commented 4 years ago

Because the shape of how we define types currently makes them un-mergeable. IIRC the original thought was to centralize on a single interface and then pass that down as a default parameter to be able to get to the types via conditionals.

I'm not certain if this is actually necessary still with how we're inferring them now via the globals and "materializing" the types dynamically via infer, it's been on the todo list of design assumptions to revisit.