apollo-tooling
apollo-tooling copied to clipboard
Any way to disable globalTypes generation?
I'm trying to use codegen in an existing codebase and can't run it on all files as that fails due to numerous issues (imported fragments from other modules, anonymous operations, etc)
What I've instead been doing is running codegen on new code. It works but whenever globalTypes is generated it overwrites previous data – this leaves older operation types without enums
Is there a way to disable globalTypes generation and keep enums local?
I'm also interested by this, but for different reasons: I'm generating code for a few GraphQL queries using the Apollo CLI codegen feature, but in my case the globalTypes.ts file is empty, so I assume that I simply don't need it.
The issue is that I'm using the Create React App scripts in my project, and it enforces the isolatedModules
option to true
. Having empty files is not allowed when that option is enabled.
For now my workaround is to instruct the CLI to generate the globalTypes file outside the compilation scope, but this is a dirt hack that I'd like to avoid :)
Any idea of another (cleaner) solution? I feel like disabling the generation of that empty file would be ideal in my case.
I simply exclude the globalTypes.ts
in my tsconfig.json
and it workes as promised.
i think apollo should not generate the global-types if its empty. it results in errors also for next.js because that forces isolatedModules to be true as well
+1
damn, just run into that again. Does anyone know a workaround?
any news on this one?
Hi, I am also curious if there's a fix for that.
FTR: there seems to be an open PR related to this, but it's still open: https://github.com/apollographql/apollo-tooling/pull/2163.
I got around this issue with the setting --globalTypesFile src/__generated-globals__/globalTypes.d.ts
.
I got around this issue with the setting
--globalTypesFile src/__generated-globals__/globalTypes.d.ts
.
You are putting it outside of the compilation scope which works put is not really "clean". A simple --globalTypesFile false
would be enough but somehow no one seems to care...
@Manubi I totally agree, just adding another workaround for people that need to get on with it in the mean time.
If globalTypes.ts
is empty and you often generate types with the help of a custom script in package.json
like I do, you can simply delete the empty file programatically:
"types:generate": "npx apollo codegen:generate --localSchemaFile=graphql-schema.json --target=typescript --outputFlat --addTypename src/types && rm src/types/globalTypes.ts"
any workaround for this? Its a really annoying problem that would be easy to avoid.
+1 very annoying.
I was getting this error
'globalTypes.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module. TS1208
My workaround is to change the file extension: --globalTypesFile globalTypes.d.ts
.
The typescript compiler treats d.ts
as a declaration file, not a "global script file", and has no problem with empty declaration files. I imagine this will break if codegen:generate
ever decides to generate anything besides comments.
I got around this issue with the setting
--globalTypesFile src/__generated-globals__/globalTypes.d.ts
.You are putting it outside of the compilation scope which works put is not really "clean". A simple
--globalTypesFile false
would be enough but somehow no one seems to care...
I actually care and your solution helped me. Thank you very much @Manubi !
You are putting it outside of the compilation scope which works put is not really "clean". A simple
--globalTypesFile false
would be enough but somehow no one seems to care...
This seemed to me like you are making a suggestion to implement "--globalTypesFile false", but thanks to @pamplonapaulo I realised it does already work that way, thanks!
FYI: the type definition generator has been deprecated.
https://github.com/apollographql/apollo-tooling/blob/785b86eba208e5c3a7a77f274e4c6b695d102c47/packages/apollo/src/commands/client/codegen.ts#L135-L138
Hence, I don't believe issues like this one will be fixed anymore.