Skip to content

Sustainability of dependencies #3127

@IgnatBeresnev

Description

@IgnatBeresnev

Background

Dokka has a number of dependencies used for analyzing projects. Half of these dependencies must be updated every Kotlin release (like the Kotlin compiler and KGP). Unfortunately, not all of these dependencies (or their API) are stable or even meant to be used externally.

This past year, almost every single release, Dokka's maintainers had to spend a lot of time on resolving compatibility issues and transitive bugs that arise due to the updates. This leads to maintainers being frustrated and having to waste their time on fighting the dependencies rather than improving the product. And it leads to Dokka's users being frustrated because their projects also (as a consequence) start experiencing issues or get simply broken (#2977, #3081, #3038).

Goals

The main goal of this epic is to get Dokka's dependencies under control, to stabilize them as much as possible (or migrate to the stable API), and to identify upstream problems as soon as they are introduced, not months later.

More specifically,

  • Improve predictability of maintenance. Dependency updates should not take weeks.
  • Improve stability of Dokka from the user's perspective. Updating Kotlin in a user project should not cause Dokka to fail all of a sudden.
  • Add Dokka to Kotlin's aggregate builds, so that compatibility problems introduced to any of Dokka's dependencies (like the compiler or KGP) will fail the aggregate build.
  • Research if it's possible to include Dokka into the EAP program.

Dependencies

Evaluation of Dokka's hard dependencies:

  • Kotlin Gradle Plugin (KGP):
    • Must be updated to the latest after every Kotlin release.
    • Dokka relies on it for project autoconfiguration (resolve platforms, source sets, classpath, etc).
    • Dokka uses some semi-internal / undocumented API, which tends to be unstable or gets deprecated/changed often.
    • At the moment, the biggest source of pain.
  • K1:
    • Dokka depends heavily on the org.jetbrains.kotlin:kotlin-compiler artifact.
    • Dokka depends heavily on org.jetbrains.kotlin:idea and related artifacts (not anymore, addressed in Get rid of the dependency on Kotlin IDE plugins #2889)
    • Still used and needs to be updated every release until Dokka migrates to K2.
    • Less problems than with KGP, but occasional API changes and smaller underlying behaviour changes that are hard to spot.
  • K2:
    • Stable compiler API is in the works, and at the moment it's not urgent as K2 analysis hasn't even been released.
    • To avoid the same mistake as with K1, we are starting to work on this in advance, see [K2] Use only stable compiler API #3141
  • IntelliJ platform:
    • Multiple artifacts from the com.jetbrains.intellij package.
    • Used for Java source code analysis, as well as for some Kotlin parsing.
    • Needs to be updated only when kotlin-compiler also updates it, as parts of it are used and bundled in the compiler, and our versions need to match. Happens rarely.
    • Mostly stable, haven't had many major problems with it.
  • Markdown:
    • org.jetbrains:markdown artifact.
    • Used for parsing module/package documentation (plain Markdown files), and some other minor things.
    • Mostly stable, haven't had to update it frequently.
  • JPS (removed as part of Get rid of the dependency on Kotlin IDE plugins #2889)
    • An internal build tool for IntelliJ IDEs
    • Completely unrelated, not used and not needed by Dokka
    • Came as a transitive dependency with IDE artifacts

Subtasks

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementAn issue for a feature or an overall improvementepicA large body of work that is broken down into smaller issuestech-debtA technical issue that is not observable by the users, but improves maintainers quality of life

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions