Questions about new ApolloCompilerPlugin API

[edenman]

Question

Looking at the new ApolloCompilerPlugin stuff in 4.0 beta 6. Coming from 4.0 beta 4 where we have an operationIdGenerator and we're also setting a compilerKotlinHooks. I converted the compilerKotlinHooks to a ApolloCompilerPlugin but then I get this error Apollo: using ApolloCompilerPlugin and operationOutputGenerator/operationIdGenerator/packageNameGenerator at the same time is not supported. See https://go.apollo.dev/ak-compiler-plugins for more details.

Sounds like the new recommended approach is to have a single plugin that does all of this stuff? If that's the case,

• Is OperationDescriptor.source the equivalent of OperationIdGenerator.apply's operationDocument param?
• Is there any way to access the org.gradle.api.logging.Logger from the compiler plugin?
• Is there any way to access gradle params like gradle.startParameter.isOffline from the plugin?

For context, this is our old operationIdGenerator:

        private val isRunningOnCi = System.getenv("CI") != null

        operationIdGenerator =
            if (gradle.startParameter.isOffline || isRunningOnCi) {
                OfflineIdOperationGenerator(logger)
            } else {
                serverOperationIdGenerator
            }

(Let me know if you'd prefer to discuss this on Slack, I just figured there's not much discussion on this stuff yet so it might be more helpful to be more publicly searchable)

[martinbonnin]

Hey! Thanks for posting this. GitHub definitely has better SEO so that's a good place 👍

Sounds like the new recommended approach is to have a single plugin that does all of this stuff?

Yes, it'll ultimately allow us to isolate the compiler into its own classloader so we can remove the current relocation we're doing and more generally separate the concerns.

Is OperationDescriptor.source the equivalent of OperationIdGenerator.apply's operationDocument param?

Yup, correct. I'll make a migration guide for this.

Is there any way to access the org.gradle.api.logging.Logger from the compiler plugin?

You might be able to add gradleApi() to your compiler plugin and call Logging.getLogger() but I wouldn't recommend it. We might want to isolate the plugin even more. I'll look at what KSP is doing. The setup is the similar, in the end I think it should match.

Is there any way to access gradle params like gradle.startParameter.isOffline from the plugin?

I think codegenerating them using something like BuildConfigFields would work (this part of the doc)? It's not optimal because this value changing means you have to recompile your plugin but in practice it shouldn't be too much of an issue.

KSP has args for this but from a quick cursory look it doesn't provide type safety (it looks all string based). I'll dig more.

[martinbonnin]

Re: logging, looking at KSP source code, looks like it is all System.out based and they're passing the loglevel to the task. We could do the same so that at least ./gradlew -d, ./gradlew -i, etc... would be forwarded to the Apollo compiler plugin logs. Would that work?

[edenman]

Is there any way to access gradle params like gradle.startParameter.isOffline from the plugin?

I think codegenerating them using something like BuildConfigFields would work (this part of the doc)? It's not optimal because this value changing means you have to recompile your plugin but in practice it shouldn't be too much of an issue.

KSP has args for this but from a quick cursory look it doesn't provide type safety (it looks all string based). I'll dig more.

Yeah I'm wary of the BuildConfigFields approach triggering unnecessary module rebuilds but not sure if that's a real concern. I'm a bit out of my depth here. Maybe we could set it as a system env var?

[martinbonnin]

set it as a system env var?

The issue is we need to make Gradle aware of any parameter for up-to-date checks, etc... If you have several parameters, it means either serializing them all to a single Gradle input (probably what KSP is doing) or something else (maybe pass a Map or so). This week is packed already but I'll look into it early next week.

[martinbonnin]

First drop for parameters and logger here