Generated code size on 1.0 exponentially large than 0.51.2

[tahirmt]

Summary

Hi for versions 0.5x we have been using the mergeInFieldsFromFragmentSpreads option turned off because the code size was too large using it however with 1.0 that option is no longer optional which is a good thing in terms of ease of use however our code generated files have gone from 68k lines to 364K lines with 1.0.5.

This might not have been an issue however the compiled framework with just the generated code size has gone from 18MB to an over 500MB making it impossible for us to get this update to production.

The compilation time for just the generated swift files has gone from 8s to ~170s.

Is there anything we can do to improve this? We would like to be on the major release but these things are preventing us from adopting the first major release.

Version

1.0.5

Steps to reproduce the behavior

It's hard for me to share the actual schema because it's proprietary but I will provide some additional information... We have a lot of fragments (162). We heavily use directives to include/skip fields/fragments. We have tons of fragments that have other fragments inside it. e.g

fragment GenericFragment on GenericType {
   commonField
   ... FirstSpecificFragment
   ... SecondSpecificFragment
   ... ThirdSpecificFragment
}

fragment FirstSpecificFragment on OtherType {
   ... OneKindOfFragment
   ... OtherKindOfFragment
}

There are 26 mutations, 48 queries and 20 subscriptions that utilize some parts of these fragments or use inline fragments.

Logs

No response

Anything else?

No response

[pm-dev]

@tahirmt This looks like a dupe of #2560

[tahirmt]

It can be considered as a duplicate but ideally it would be nice if there was a way to reduce the generated code size without losing the benefits. For example not generating the same type under the namespace of every single operation it's used. Not sure how possible that is.

Edit: looks like this solution is already discussed there.

[calvincestari]

@pm-dev is correct, this issue is the same as #2560.

Currently there is no way to prevent the code explosion you're experiencing; it's directly related to nested fragments. The solution is to implement the same mergeInFieldsFromFragmentSpreads option in the 1.0 code generation engine.