Break generated exec code into subpackages?

[henrywoody]

Is it possible to break the code generated by the exec section of the config into subpackages?

Motivation: I have a fairly large project and the generated exec code is about 1 million lines of code. Since all this code is in one package, any change, even a tiny one like fixing a typo, requires recompiling the whole package which can take a few minutes, which really slows down development. Breaking the code into subpackages would allow for partial build-caching of the generated package and improve build times in development.

I've found other related issues, for example #1265, that talk about splitting the generated exec code into separate files, but not into separate packages.

Ent does something like this by putting each model in its own package within the ent package so that changes to a single model minimize recompiling (their motivation may have been different, but that is a benefit).

[StevenACoffman]

Thanks for bringing this up! We thought about it, but weren't sure if it was worth it! The single-file layout is for quick small proof of concepts to get up and running fast. The follow-schema layout is for bigger and more complicated projects. Supporting both was already a lot of configuration and code complexity for people to handle.

The current follow-schema layout configuration does not allow you to specify a directory template (and/or subpackage template). It wouldn't be much work to adjust it though.

1. Change the code to accept an alternative to dir like dir_template and an alternative to package package_template
2. Figure out nice names for the organizational sections to split on
3. Update all the places to use the correct "sectional" package names and make some new generated things exported

For any PR to be accepted, the change needs to avoid breaking people's existing configuration.

For reference, this is the existing config of the exec section:

# Where should the generated server code go?
exec:
  package: graph
  dir: graph
  filename_template: "{name}.generated.go"

By the way, if you are not already aware of it, you should also know about the config option use_function_syntax_for_execution_context which was added in #3407 . Otherwise, once more than 65,000 methods have been added to the executionContext the Go compiler fails.