Add option to generate objects with internal access modifier

[simonbilskyrollins]

Feature request

Add option to generate objects with internal access modifier.

Motivation

All of the objects generated by Apollo codegen currently have the public access modifier. This setup is great if you need to use generated objects across module boundaries, but if you do not then all of that public code can negatively affect both compile times and app size. Adding a codegen option to make these objects internal instead of public would fix these problems.

I believe this request is the same as #149 which was closed and completed, but the functionality does not yet exist in 1.x.

[calvincestari]

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

Are you proposing changing the access modifier for just operation models, all generated code or a more intelligent where-possible approach?

I can see a case being made for all operation model code to be internal; schema models too but only in the case of an .embeddedInTarget(name:) module type. When the schema types are in their own module they will need to remain public.

[simonbilskyrollins]

Hello @calvincestari!

Personally, I would like to be able to make both operation models and schema types internal because I'm using relative operation output and the .embeddedInTarget module type. However it would make sense to me to specify access modifiers for operation models and schema types independently via configuration properties in output.operations and output.schemaTypes.

I do see some opportunities to make this functionality more intelligent than a simple internal vs. public switch; for example, I would expect Apollo to warn you in some way if you tried to generate internal schema types in a standalone schema module.

[calvincestari]

I'm a strong advocate for less configuration options, IMO there are too many already. 😬

I think we might be able to get away with a single enum option, as was available in 0.x, and the codegen engine does what it can to match, i.e.: in the case standalone schema modules it simply remains public.

[simonbilskyrollins]

Fair enough! If we can make this work with a single configuration option that's definitely the way we should go.

[derrh]

I'm interested in this feature as well, but I'd like to be able to control access to fragment types a bit more fine-grained. For most operations I'd prefer internal, but for a very few rare cases I'd like to create shared fragments (when associated with shared reusable SwiftUI components). What about providing a custom GraphQL directive that could be applied to an operation or fragment to control module access?

[calvincestari]

What about providing a custom GraphQL directive that could be applied to an operation or fragment to control module access?

There are many places we'd love to support custom directives, and this one sounds like another good option for consideration.

A workaround that you could leverage at the moment is that if you are using .relative(subpath:) for output.operations then placing common fragment file definitions (.graphql files) into the location where the generated schema types module will be placed, you effectively create 'shared fragments' because they would be included with the shared schema module. It's a crude workaround but can work in limited configurations.

[calvincestari]

@simonbilskyrollins, this was released in 1.2 earlier this week. Please give it a try and let me know if it satisfies what you wanted. Thanks.