The babel typescript transformer doesn't support namespaces, so we can't use the generated types with that package.
Hi @dobesv !
I think we can support this case, but not as default behavior...
We can add it as a specific config for the typescript template (see this).
Can you please provide an example for how the output files will look like? any alternative for namespaces?
Apollo codegen uses a prefix on all the names, like XxxMutation, XxxQuery,
etc.. I had started trying to make a custom template myself to do this but
got stuck with some build problems.
On Sun, May 6, 2018, 10:38 AM Dotan Simha notifications@github.com wrote:
Hi @dobesv https://github.com/dobesv !
I think we can support this case, but not as default behavior...
We can add it as a specific config for the typescript template (see this
https://github.com/dotansimha/graphql-code-generator/pull/229#issuecomment-386896599
).Can you please provide an example for how the output files will look like?
any alternative for namespaces?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotansimha/graphql-code-generator/issues/285#issuecomment-386896999,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUAmTPLZHeN3xL3IZsHpPGI4Orbcjceks5tvzUdgaJpZM4Tz1r8
.
@dobesv, I see. so maybe now with the new CLI it will be easier to create this template :)
And I think prefixing is fine, but how we can handle a case where two types has the same name? for example, if you have query A and query B and both of them are using a field that is called User, in the existing implementation it would be:
namespace A {
export type Query = { ... }
export type User = { name: string }
}
namespace B {
export type Query = { ... }
export type User = { name: string }
}
But without namespaces, we cannot declare User again. Maybe instead of namespaces, we need to use the name of the query as prefix for all generated types, for example:
export type A_Query = { ... }
export type A_User = { name: string }
export type B_Query = { ... }
export type B_User = { name: string }
What do you think?
Hmm I didn't realize there would be multiple same-named types generated other than XxxVariables and XxxQuery and so on.
Actually I realized the namespaces are only for the client-side stuff. I can use apollo-codegen for client-side types and gql-gen for server-side types and I don't have to change anything. That's probably good enough for anyone who happens to be in my situation.
@dobesv That's great. I'm keeping it open if you don't mind - we might implement it sometime soon :)
+1 for an option to disable namespaces. We're using the same workaround that @dobesv proposed but it would be nice to have one tool (graphql-code-generator) to perform the whole type generation.
Also +1 this — currently the problem I'm running into is ts-jest fails so parse the generated type definitions because they include namespace. I'm trying to see if there is a solution for that, but in the meantime it basically means I would need to change testing frameworks or simply not use these auto-generated types, but this type generation is awesome and I'd really like to find a way to make use of it.
@dotansimha could you please publish a new release with this change? We're eagerly waiting for this :)
@damianfrizzi @dobesv @bonham000 it's available now in 0.10.4 :)
Thanks @ardatan for fixing it!
noNamespaces doesn't seem to work with typescript-resolvers, is it only for typescript-client?
@luishdz1010 Could you share your configuration?
Here it is:
schema:
- 'schema.graphql'
overwrite: true
generates:
src/gql-gen/types.ts:
plugins:
- typescript-common
- typescript-client:
noNamespaces: true
- typescript-server
- typescript-resolvers:
noNamespaces: true
Could you try like this?
schema:
- 'schema.graphql'
overwrite: true
generates:
src/gql-gen/types.ts:
config:
noNamespaces: true
plugins:
- typescript-common
- typescript-client
- typescript-server
- typescript-resolvers
Thanks, @ardatan, it's working perfectly now.
Most helpful comment
@dobesv That's great. I'm keeping it open if you don't mind - we might implement it sometime soon :)