-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Scalars generated as independent types #10233
Comments
This is an interesting use case @ThePlenkov 👀 It's a big change to both codegen and all other plugins that rely on I'm not sure if one single use case justifies this change as there's ongoing maintenance, compatibility and other things we need to consider 😅 |
Well, i definetely understand what you mean. However I'd like to highlight here several points:
So instead of
we can do something like:
or even preferably just like this:
This would make it still possible to access by index like we do now : What is important to me is that we need to use in operation types/ fragments reference to standalone types, not Scalar type. For this Gitlab example, even for 1 query my dts file size in lines is 1712 lines ( including comments ), |
Is your feature request related to a problem? Please describe.
I'm using code generator to generate SDK for certain predefined queries for a very large graphql schema ( Gitlab ).
For that purpose I'm using
onlyOperationTypes: true
however even in this case it generates all enums and all types as it's described in #10232 .So I solved my problem by use of knip.dev tool which is if run like
knip --fix --exports
removing exports from unused types and then in combination with bundler it makes a perfect result only bundling used types to d.ts fileHowever there is still a problem.
Gitlab is using many different scalars ( like logical separation for different uids ). Because gcg creates Scalars like this:
those types are exported as one single type and cannot be excluded separately.
Therefore I'd like to find the way how to export only those Scalar types which are required.
Describe the solution you'd like
Possible solution is to introduce an option like
standaloneScalarTypes
which can be prefixed like Scalar_ or may be even wrapped into Scalars namespace instead.This would allow us to exclude not used scalar types and only export what is in real use. The size of the bundle will reduce significantly.
What do you think of this idea?
Describe alternatives you've considered
No response
Any additional important details?
No response
The text was updated successfully, but these errors were encountered: