Enable operations-only code generation

[derrh]

Feature request

One goal I've been exploring for a large project is the ability to generate a Schema Types module and Operations modules independently and is separate repos.

Motivation

I'd like to allow feature modules to perform codegen for their own operations, but depend on a pre-existing, schema-types module. As a feature module owner, I could maintain my own repo/SPM module that depends on a remote schema-types repo. My feature module could provide it's own codegen config but not regenerate the schema types files.

Proposed solution

Make the schemaTypes field optional on FileOutputs or provide a none case in SchemaTypesFileOutput.ModuleType. In either case, if .none is requested, the schema types files are not codegen'd. Generated operations files would import schema types from the module identified by SchemaName.

Outstanding Questions

Perhaps this is a workflow you've already considered and there is a solution in place?

1.0 is looking great! Thanks!

[calvincestari]

Hi @derrh 👋🏻 - thanks for the feature request.

I think you might be able to already achieve the separate repos with the current config by simply using the correct paths, which would lead to separate repo locations. I haven't tried it so I cannot say for certain but I believe the operation file import statements will still work as expected because a separate schema module is already an option in FileOutput. SchemaTypesFileOutput. ModuleType. It is not currently possible to only generate operation files though.

A detail you may not be aware of is that parsing the schema and operations would still be required even if you only wanted the operation files to be generated. This is because of the AST that is produced during that parsing and is used by the operation templates to generate those files will full knowledge of all the available schema types. So the only step you'd be 'skipping' is writing the schema files, which seems quite inefficient.

If the AST were able to be persisted externally and then referenced during operation file creation I could see a path to this working. Honestly though I don't think this is something we will end up implementing and supporting ourselves. You are always able to fork the repo, implement the feature, and then contribute it back if you feel it's of value to the wider community.

[derrh]

Circling back to this. I can see how this might not be an advisable approach. Another realization I've had is that the generated schema types are a subset of the total graph's types depending on the operations, which means that in many cases updating the changes for a feature package's operations would result in changes to the schema package's types as well. Still exploring options, but leaning more toward a monorepo with separate packages.

[calvincestari]

Another realization I've had is that the generated schema types are a subset of the total graph's types depending on the operations, which means that in many cases updating the changes for a feature package's operations would result in changes to the schema package's types as well.

Yes, this is correct. Rather than generate every type in the schema, only the referenced types are generated into the schema types module. When you consider large schemas such as the GitHub schema it makes sense why.

[AnthonyMDev]

We're going to track this in #3165. Closing this as duplicate

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.