What is your opinion on compiler plugins w.r.t. ve...

# getting-started

[Arjan van Wieringen]

What is your opinion on compiler plugins w.r.t. version management and dependencies? I am not a plugin author so I don't know the intricacies, but I've noticed quite a few new libraries which use the Kotlin Compiler plugin architecture. This is great because it adds a lot of flexibility, however I also notice very high coupling to specific Kotlin versions. This results in the fact that multiple libraries now have hard dependencies on a specific Kotlin version. E.g., library:1.4.0 requires kotlin:1.9.20 and library:1.5.0 requires 1.9.21. Or you get library:1.4.0-1.921 and library:1.4.0-2.0.20. To me this is quite problematic to adopt libraries in projects. With one such a dependency it is doable, but if you have multiple it sometimes means you can not update Kotlin because 1 dependency is not updated.
Even worse, some library has a necessary bugfix and bumps its dependency to Kotlin to a later version, however you're still stuck on an older Kotlin version because another library is not yet updated.

With 'normal' dependencies they have to do something pretty funky to not be compatible with a new Kotlin version, but by being dependent on the Compiler architecture the backwards compatibility is broken way too fast, resulting in hard upgrade paths in larger projects.

[CLOVIS]

Yeah, it's a problem, but sadly there isn't much we can do about it.

For example, take Kotest. Kotest frequently breaks on new Kotlin versions because it uses a compiler plugin to collect test methods. But there's no other way to implement it.

[Johann Pardanaud]

Until the compiler API becomes stable, there is not much to do.

However, if the library has a stable enough API, it is possible to do just like kotlinx.serialization:

• a compiler plugin with a version number following Kotlin's one ;
• and library dependencies with their own version numbers.
It decouples the updates of the compiler plugin from the library itself. You can release a bugfix for your library without having to release a new compiler plugin.

But it requires to have a stable enough API, because the compiler plugin can't introduce backward incompatible changes.

[hfhbd]

But on the other hand, having different compiler plugin and runtime versions causes also confusions to the users because you need to find the correct Kotlin compiler version, the matching compiler plugin version and the matching runtime version.

[Arjan van Wieringen]

@Johann Pardanaud
"a compiler plugin with a version number following Kotlin's one". But that's already a problem now, because quite some library authors are too busy to update their plugins to follow Kotlin.

[Johann Pardanaud]

I totally agree, but this will continue to be an issue until the compiler API is stabilized