with Dagger’s upcoming support for KSP, I’m lookin...

# ksp

[Zac Sweers]

with Dagger’s upcoming support for KSP, I’m looking at trying to support it in github.com/square/anvil and wanted to bounce some ideas here.

It’s a bit tricky, as it has always worked up to this point by running a special IR plugin during kapt stub generation to modify/add annotations to certain classes for Dagger’s use in kapt. Obviously that won’t work in a KSP world since it’s all one task.

What I’m thinking currently is something clever like this:
• Anvil exposes its own delegating SymbolProcessor that handles running Dagger’s.
• It would then decorate KSP’s Resolver APIs to intercept them and add this metadata (annotations, etc) to the KSP types on their way through.
So for example, this type

@MergeComponent(...)
interface AppComponent

This processor would then intercept that and construct a new KSClassDeclaration that almost entirely mirrors the previous except that it adds the merged @Component annotation that anvil synthesizes instead.

Lastly, when resolving annotated elements, it would intercept searches for Component types and forward the request as a @MergeComponent request instead.

Same patterns would be used for merged modules.

While weird and obviously not something KSP could officially support, I do think this could work more or less entirely within the bounds of KSP’s public API. Does this seem like a reasonable approach? Or any dragons on the path that I’d run into?

[Ting-Yuan Huang]

Sounds feasible to me. A couple of random comments:
1. Loading dagger could be a little tricky. Currently, KSP pulls all ksp(...) dependencies into compiler plugin classpath and loads all processors discovered. You may need to fetch and load dagger separately, which can be error prone, or let's figure out how KSP can support this better.
2. The decorator will need to be maintained to keep up with KSP's API

[Ting-Yuan Huang]

You may also need to check whether there are relevant casts to underlying implantations in dagger. IIRC it casts environment into javac's implementation.

[Jiaxiang]

with regard to pulling all processors, we already have support for filtering processor by given names in CLI, expose it in Gradle in someway should work the purpose.

[Jiaxiang]

context: https://github.com/google/ksp/pull/1014

[Zac Sweers]

would offering the inverse make sense? i.e. an option to exclude only certain processors by name?

[Ting-Yuan Huang]

I'm thinking whether we should only load processors that are explicitly specified in the ksp dependencies. Indirect dependencies will still be accessible in the plugin classpath, but KSP should not load them. In this way, Anvil can declare the dependency on Dagger, having them available in classpath, without running them automatically.

On the other hand, this is a behavior change. A processor previously worked with Dagger would then require its users to declare Dagger explicitly

[Zac Sweers]

That does sound a bit sticky to deduce. IMO I think it would be enough to just offer filtering options