This repository was archived by the owner on May 28, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 221
This repository was archived by the owner on May 28, 2025. It is now read-only.
Migrate KTS Plugins to KT for Compatibility and Future K2 Support #552
Copy link
Copy link
Open
Labels
refactorrefactoringrefactoring
Description
We are proposing to migrate our KTS (Kotlin Script) plugins to regular Kotlin (KT) in order to ensure better compatibility with the latest versions of IntelliJ IDEA and to make it easier to add K2 support in the future. Below is the reasoning behind this proposed migration.
Context and Rationale:
-
IDE Support:
- KTS has increasingly unreliable support in modern IDEs, especially IntelliJ IDEA. As newer Kotlin and IntelliJ versions are released, the KTS feature set often lags behind, leading to compatibility issues.
- Migrating to KT will allow us to stay updated with the latest tooling and avoid being locked to outdated versions of IntelliJ or Kotlin.
-
K2 Compatibility:
- Kotlin K2 is the new compiler under active development, which introduces significant changes. As seen in previous updates, KTS can become fragile with major language/compiler shifts, and this is a risk we want to avoid.
-
Boilerplate Reduction vs. Fragility:
- While KTS reduces boilerplate code in some cases, such as when defining classes like
TestPlugin: Plugin, this benefit does not justify the instability of using KTS, especially as it relates to newer Kotlin versions. - KTS also introduces implicit behaviors (e.g., implicit imports) which make the code harder to follow for both new and experienced developers.
- While KTS reduces boilerplate code in some cases, such as when defining classes like
-
Dependency Injection (DI) Issues:
- Since all code within KTS files is placed into the Kotlin-generated class constructor (which we have no way to access within code), we are forced to rely on an inject() method for injecting dependencies into our code. To create such a function, each KTS class now requires access to the Injector, which, when using Guice, contradicts the best practice of "using the Injector as sparingly as possible, preferably only once." All code throughout the script file has access to this method, allowing developers to call it at runtime without any restrictions, which can be quite dangerous.
-
KTS is Heavily "Magic" Dependent:
- KTS involves a level of abstraction ("magic") that is challenging for developers to follow, increasing the learning curve and decreasing overall code clarity.
- Relying on compiler "magic" can obscure code functionality, making it difficult to debug and maintain.
-
Neglected Maintenance:
- The KTS ecosystem has been relatively neglected by its maintainers, with fewer updates and bug fixes compared to regular Kotlin. This leads to increased fragility in the face of updates to Kotlin or IntelliJ IDEA.
-
Limited Usage Scenarios:
- The way we are using KTS in RSPS does not align with the vision of its primary maintainer, further complicating its viability for long-term support.
Metadata
Metadata
Assignees
Labels
refactorrefactoringrefactoring
Type
Projects
Status
Todo