Conditionally mark generated classes as internal

[rmberg]

Summary It would be nice to have the ability to conditionally mark some generated classes as internal instead of the global generateAsInternal.set(true) which sets all generated classes to internal. The use case is to mark most generated classes as internal to avoid leaking the internals (pun intended?) of a multiplatform SDK, but allow some useful classes like enums to still be exposed externally. Maybe another option would be to specify something like generateEnumsAsInternal.set(false)?

Version 3.3.2

[martinbonnin]

Hi 👋

If we're going down that road, I'd suggest to either:

1. have a lower level compiler API (see https://github.com/apollographql/apollo-kotlin/issues/4026) that would give you a KotlinPoet TypeSpec that you can customize
2. or some GraphQL directive to give more control over the generated code:

# extra.graphqls

extend type MyEnum @codegenOptions(internal: false)

It adds significant complexity to the codegen though... Maybe there's another way to achieve a similar result? If the goal is to expose enums, you could write mappers manually. If manual is not an option, you could have your own codegen task? Even maybe add them in some apollo-kotlin-labs repo?

[rmberg]

Hi @martinbonnin, yes my current approach is to map the generated classes and enums to my own domain objects using a toModel() extension method on the fragment classes. It works well enough for now, but generally I thought it might be nice to conditionally mark certain classes or generated objects as internal or public. It wouldn't have to be limited to enums. I do like the idea of adding a directive to the graphql, my guess is it would be very similar to the @nonnull directive that already exists, no? Perhaps I can take a try on a PR for that.

[martinbonnin]

GraphQL directives are a very powerful tool but also I'd like to avoid adding too many of them before we end up in this situation 😅:

Let's wait a bit see if there are more feedbacks? Or if it becomes too much of an issue for you, let's revisit with a more detailed use case?

[martinbonnin]

@rmberg You can know use the KotlinCompilerHooks API from 3.7.0 to do so. You can find an example in the integration tests: https://github.com/apollographql/apollo-kotlin/blob/fb51dafaa4b02a55b6926546927d176078513543/libraries/apollo-compiler/src/main/kotlin/com/apollographql/apollo3/compiler/hooks/internal/AddInternalCompilerHooks.kt#L10

Let us know how that works for you.

[rmberg]

Thank you @martinbonnin, we'll check it out!

[martinbonnin]

Hi @rmberg did you get a chance to try it? Anything else we can help with here?

[martinbonnin]

I'm going to close this one for now, feel free to comment if the KotlinCompilerHooks solution doesn't work and we'll dive more.