Closed LiLatee closed 7 months ago
Hi!
I'm sorry to hear that you have such problems migrating to ferry.
I assume this is due to built_value, which generates a lot of additional boilerplate and also collects all serializers in the serializers.g.dart file, which, I assume will consume a lot of memory when compiling.
I can think of a few avenues how to reduce the size of the generated code;
I do have a full time job as well, so I can't promise any quick solutions, unfortunately.
Thanks a lot for such a quick response 😊
All of the above points are just ideas to improve, not ready to use for now, right?
Yes.
I implemented a quick workaround that you can try out;
it's on branch workaround/non-serializer-reqs
It removes the xxxxReq classes from the serializers.gql.dart file.
This means, calling toJson() on them won't work anymore, and the offlineMutationLink which persists queries on offline mode to send them later will break because of this, but other than that everything should continue to work.
Maybe that's enough for compilation to succeed.
You can also try disabling when(), maybeWhen() methods on union types if you don't need them.
Probably can be closed for now. The issue has been explained here https://github.com/gql-dart/ferry/issues/558#issuecomment-1865189940
Hi! It's me again. ferry has generated about 2.2k files and 2.7mln lines of code. The whole
lib
directory has about 3.7k files. And now we are not able to build the app in release mode. It was running 3 hours (M2 pro, 32GB) and threwOut of memory
error.We are trying to switch from artemis, which generates just 2 files (about 400k lines). It was also problematic to work with such big files, but build_runner takes a few minutes as well as the building of the app in the release mode.
Any ideas for such a problem? 😞