Comparison with amzn/kotlin-inject-anvil

[bddckr]

Hey there, thanks for open-sourcing this!

I'm currently using Dagger 2 + Anvil and am looking for solutions to move my codebase to K2 and set the language version to 2.0.0 or later.

I've almost gotten https://github.com/ZacSweers/anvil to work with my codebase, but now that my custom code generator uses KSP, I'm re-evaluating the options. I'm interested in moving to https://github.com/evant/kotlin-inject. Not wanting to give up on what boilerplate removal Anvil brings, I've since found this project and https://github.com/amzn/kotlin-inject-anvil.

---

Do you have any thoughts on this project vs. Amazon's alternative?

_{Note: I'm just asking about obvious differences that are worth calling out. Don't dive deep or even properly review the other project, of course!}

It looks like theirs works very similarly to how Zac Sweers's Anvil fork works - except, of course, it's for kotlin-inject and not Dagger 2. I'm interested in understanding the pros/cons. So far, it looks like kimchi is simple enough to use, and looking at the recent activity, it's not only actively maintained, but the changes are making it look like it's easy enough for a KSP newbie like myself to resolve issues myself and contribute in the long run, if required.

From a first look at the readmes only, it looks like both kimchi and Amazon's kotlin-inject-anvil work mostly the same. However, support for custom code generators seems easier to set up with kimchi.

My code generator doesn't use a custom annotation - I instead find all files to process based on a naming convention. Without setting it up yet, it seems kimchi will work just fine with that, as long as I don't break the multi-round processing of KSP (by e.g. raising an error, which would stop the processing after the current round finishes). Maybe kotlin-inject-anvil works fine with that as well, but I'd have to test that - the documentation makes it seem like it requires an annotation to be used.

[r0adkll]

Hey @bddckr ! Thank you so much for posting this discussion! It is definitely something worth addressing.

TL;DR kotlin-inject-anvil is probably the more pragmatic option here.

So a little background first. I started to develop this tool last year for a side project and as life got busy I shelved it until recently for another side project. By the time I had finished it I completely missed that another solution had been developed and in discussion. It was a great learning experience for me and I plan to maintain it for myself and others who wish to use it. However, kotlin-inject-anvil is in use in production by that team at Amazon and has been for several months so it's definitely hardened more than my solution here. In the end this is a decision for developers and/or their teams with the requirements and risks for a 3rd party library.

---

From a technical perspective the libraries are nearly identical in functionality and have few API differences which shouldn't really impact the choice of one over the other. I should say that if you use slackhq/circuit it now has native support for kotlin-inject-anvil.

Looking at the codegen between the libraries and your described use case it seems that both would behave in a similar way and suffer from the same issue. That being the potential to miss your generated code during the merging phase. Right now this would be the case for kimchi even with custom annotations and is something kotlin-inject-merge solves with their custom annotation marker @ContributesAnnotation.

If my understanding of KSP is correct, and I'm not 100% that it is 😄, your generator would mostly be okay if you are generating in a module that is also not using a @MergeComponent annotation, or has that annotation and other vanilla @Contributes* usages. The later being that the merging phase will be deferred do to detecting @Contributes* annotations in the first round in which your symbol processor would get a chance to generate its code. Then in the 2nd round that generated code would defer the merging to a third round. However, this I believe is prone to issues during incremental compilation.

I think this is something that can be solved for your use case, but IMO not using an annotation makes the intent less clear and harder to maintain for others who might come across it. Where as marking it with an annotation makes the behavior more explicit and provides a cleaner solution to the problem outlined above.

[bddckr]

Thanks so much for the reply! Lots of great info, much appreciated!

I should say that if you use slackhq/circuit it now has native support for kotlin-inject-anvil.

Ha, that timing. That resolves this whole question for me - a great sign of support (besides the fact that Amazon uses it in production, as you said).

Thanks for being so open and honest! I learned a lot of KSP stuff by studying this project, which was easier to follow than most other KSP-using projects I've found.

---

However, this I believe is prone to issues during incremental compilation.

That indeed looks like the issue I'm running into. I got it to work, except for some edge cases. My code generator is producing code that another generator will later "fix", but these Anvil-like processors all see the erroring symbol in the meantime. I can work around it and maybe even find the culprit to contribute some improvements so the symbol is deferred instead of leading to an error.

IMO not using an annotation makes the intent less clear and harder to maintain for others who might come across it

You're not wrong! 😄 It's just a little noisy and easy to get confused when you did everything correctly (subclass a known base class), only to notice minutes later that you forgot the annotation.
That said, it definitely looks like the path of least resistance for any of these Anvil-like plugins, so I'll most likely go ahead with that. I can still give a nice error when a dev forgets to annotate - after all, I can look up based on file naming convention, etc. and then check whether the annotation is missing.

[r0adkll]

Thanks for being so open and honest! I learned a lot of KSP stuff by studying this project, which was easier to follow than most other KSP-using projects I've found.

Absolutely! If you've learned a lot and enjoyed the project then that has made developing and open-sourcing it worth it!

I can still give a nice error when a dev forgets to annotate - after all, I can look up based on file naming convention, etc. and then check whether the annotation is missing.

This is something we've used custom lint rules for in the past to great success. They can help to surface that error directly to the developer without having to compile/run anything.