For FIR plugins, how do y'all keep first party plu...

# compiler

[Zac Sweers]

For FIR plugins, how do y'all keep first party plugins compatible with different versions of the Kotlin plugin? I've noticed that there are ABI breakages pretty regularly across different versions of the kotlin IDE plugin between studio, intellij, EAPs, etc. I'm not sure if it's possible to conditionally check which version of Kotlin is running in the IDE during FIR as well?

[bnorm]

I believe first party compiler-plugins are bundled with the IDE along with the analysis API. You can see what version is being used in the "About IntelliJ IDEA" window under "Kotlin analyzer version". That's essentially the Kotlin version your compiler plugin needs to be compatible with to for sure work in the IDE.

cc: @Roman Golyshev

[dmitriy.novozhilov]

That's right.
There is a (little hacky) logic in the IDE plugin, which looks for names of plugin jars passed to the compilation, determines which of these plugins are first-party and loads bundled versions of then in the IDE

[Zac Sweers]

Iiiinteresting, that explains why they seem to work seamlessly 😅 . I’m curious if yall have ideas around how third party plugins will be able to manage this. Obviously a stable API could help, but maybe in the near term maybe there could be a stricter version match between the IDE kotlin version and the plugin such that the IDE doesn’t try to load mismatched ones? Thinking like how IJ plugins can specify a range

[dmitriy.novozhilov]

The problem here is that the compiler bundled to IDE is updated every week to a fresh kotlin master in intellij and a few times after branching.
So compiler versions in the plugin and ide never match

[Zac Sweers]

Right, that’s why I was thinking maybe a range

[Zac Sweers]

But I don’t know how much FIR APIs are breaking heh

[dmitriy.novozhilov]

It could break drastically in a few commits. Or don't break at all in a year.

We thought about some intermediate solution for this problem several times already and haven't found any solution

[Zac Sweers]

Are associated tags published? Maybe if a matrix of IDE plugin version -> kotlin repo tag were available, ambitious plugin authors could publish compatible versions for each?

[dmitriy.novozhilov]

Not always, iirc.
cc @Roman Golyshev

[Zac Sweers]

another thought is possibly leveraging gradle metadata to publish information about compatible plugin jars. Basically a plugin could publish with variant information plugin jar coordinates the IDE should use that could version match, albeit tied to the build system

[dmitriy.novozhilov]

It sounds quite complicated too
cc @bnorm jic

[bnorm]

The problem with Gradle metadata is that it will basically be out of date as soon as the compiler-plugin is published. There's no way to update it about compatibility with new versions of the IDE.

I think an interesting solution here might be some kind of way to override the compiler-plugin version from within the IDE. IntelliJ already detects and disables third-party compiler-plugins by default, what if instead of disabling, it could display them as a list somewhere and allow specifying an override version string to use instead. This could also allow you to enable and disable specific compiler-plugins, removing the need for the registry key. Then if this configuration was stored in the .idea folder, it could be checked into the project as well. (Though, people using different versions of IntelliJ might be a problem.)

[Roman Golyshev]

Hi @Zac Sweers!

As previous commenters said, there is no good ways for 3rd party compiler plugins to be seamlessly integrated with the IDE. Due to the fact that there is no stable API, we cannot just reuse the compiler plugin jars provided by gradle/maven

---

One possible workaround would be something like this

First, you need to know the version of Kotlin compiler bundled into the IDE. You can do it like this:
• Enable internal mode in the IDE (https://plugins.jetbrains.com/docs/intellij/enabling-internal.html)
• After that, check the About section in the IDEA and see the Kotlin analyzer version line there (e.g. Kotlin analyzer version: 2.2.0-dev-12359)
This is the version of the Kotlin compiler that is bundled in the IDE and which you should target

Now, if in your project you
• use this version of Kotlin compiler
• use your compiler plugin compiled against that version of Kotlin compiler (you would have to obtain it somehow)
• disable kotlin.k2.only.bundled.compiler.plugins.enabled flag in the IDEA registry
then it would be possible for you to use your compiler plugin in the IDE without errors

---

I know that this does not look easy or user-friendly, and for a good reason - compiler plugins are still unstable, and we’re very cautious about providing extra support for the plugins which we do not fully control

We would consider some ways to improve this workflow for compiler plugins developers, but we cannot promise anything at this point, unfortunately

[Roman Golyshev]

I have one question regarding your particular setup: where do you publish the artifacts with the compiler plugin itself? Is it maven central?

[Zac Sweers]

yup all that makes sense. I think if there was a published matrix of IJ versions -> kotlin versions/tags that I could cut releases for that might go a long way

and yeah publishing to maven central!

[Waldemar Kornewald]

Would it be possible for the IDE plugin to substitute the compiler plugin version based on some version naming convention like kotlinver-pluginver (e.g. 2.2.0-dev-12359-1.0.0)? Then based on the Kotlin version prefix of the IDE the highest available plugin version would be picked, but only for the IDE, not the project.
With some separate mechanism (webhook or polling) the plugin's CI could trigger a build for every required release, ideally slightly before the IDE update gets released.
Am I overlooking anything?

[Waldemar Kornewald]

@Roman Golyshev @bnorm @dmitriy.novozhilov
I've added an example here:
https://github.com/ensody/kotlin-default-throws-plugin
The CI automatically checks twice daily for new Kotlin versions on GitHub, including unstable releases. If a new version is available the plugin gets rebuilt and tested. If everything is fine it gets tagged and published as version <kotlinVersion>-plugin.<pluginVersion>. This automatic process has created 2.2.0-RC-plugin.1 today. The CI could easily be extended to automatically publish with the Kotlin version used by the IDE, too. What do you think?

[dmitriy.novozhilov]

Looks very nice.
Artifacts for IDE are published to this repo, so you can extend your automation to handle it too

[Waldemar Kornewald]

Do you think this could become the general approach for all plugins? After all, even with a stable FIR, breaking IR API changes could still crash the IDE, right? Though I'm not sure if the crash would only happen when executing over IR or already when loading the compiler plugin. 🤔

[dmitriy.novozhilov]

At this moment there is no clean vision of the full API stabilization, so it's not correct to suggest some general approach.

breaking IR API changes could still crash the IDE, right?

Nope, IIRC IR plugins are not loaded at the IDE at all. It could bring some inconsistencies in evaluate expression in debugger and in bytecode viewer, but at least it wouldn't crash anything.

[Waldemar Kornewald]

OK, so the stable FIR is the actual solution that you're working towards