After updating dependencies ktlint compiles the application

[sereden]

ktlintCheck triggers a full application assembly after Gradle 8.12.1 and KSP 2.2.10 upgrade instead of performing a static code analysis check.

./gradlew ktlintCheck forces a complete rebuild of the application, including tasks like mergeDebugAndroidTestResources and compileReleaseKotlinAndroid, before running the lint checks. This significantly increases build time.

Dependency	Previous Version	Current Version
AGP	8.9.2	8.12.1
Gradle Wrapper	8.11.1	8.13
Kotlin	2.1.20	2.2.10
Ktlint	12.2.0	13.1.0

The configuration is the following

fun configureKtlintKsp(project: Project){
        project.afterEvaluate {
            tasks.named("runKtlintCheckOverCommonMainSourceSet") {
                dependsOn("kspCommonMainKotlinMetadata")
            }
            tasks.named("runKtlintFormatOverCommonMainSourceSet") {
                dependsOn("kspCommonMainKotlinMetadata")
            }
        }
    }

    fun configureKtlint(project: Project) {
        project.extensions.configure<KtlintExtension> {
            verbose.set(true)
            android.set(false) // keep false, or true only if you want Android-specific formatting rules
            outputColorName.set("RED")
            filter {
                // Lint ALL Kotlin files by default
                include("**/*.kt")

                // Exclude generated / build / irrelevant dirs
                exclude("**/build/**")
                exclude("**/generated/**")
                exclude("**/.gradle/**")
                exclude("**/ios*/**")
                exclude("**/kapt*/**")
                exclude("**/ksp/**")
                exclude("**/resources/**") // catches Compose stubs, R classes, etc.
            }
        }
    }

Does anyone experience the same problem?

[droideveloper]

Task :core:app:compileKotlinIosArm64 FAILED
Task :core:app:compileKotlinIosSimulatorArm64 FAILED

this is ci output for me on ubuntu machine, where they register everything (every source set) without checking KotlinTarget.publisable property hence everything is trying to run on

[Munzey]

This was happening to our Linux CI machine. managed to solve this by disabling in gradle.properties:

kotlin.native.enableKlibsCrossCompilation=false

added as true by default in 2.2.20

opened a ticket here: https://youtrack.jetbrains.com/issue/KT-81437/Kotlin-2.2.20-cross-compilation-breaks-KSP-iOS-targets-on-non-apple-hosts

[droideveloper]

Task :core:app:compileKotlinIosArm64 FAILED
Task :core:app:compileKotlinIosSimulatorArm64 FAILED

this is ci output for me on ubuntu machine, where they register everything (every source set) without checking KotlinTarget.publisable property hence everything is trying to run on

with use of ksp and kspCommonMain dependencies had to register tasks for targets on or after configuration where on linux and windows that they are registered regardless of using gradle.properties value set false, so I would check host and then register those targets on ksp dependencies if needed, would only work for me.

[sereden]

This was happening to our Linux CI machine. managed to solve this by disabling in gradle.properties:

kotlin.native.enableKlibsCrossCompilation=false

added as true by default in 2.2.20

opened a ticket here: https://youtrack.jetbrains.com/issue/KT-81437/Kotlin-2.2.20-cross-compilation-breaks-KSP-iOS-targets-on-non-apple-hosts

Thank you for the help.
Unfortunately, it didn't help me. Also, the issue occurs in 2.2.10 which doesn't have this flag enabled by the default

[Munzey]

ah my bad I misread 2.2.10 version!

it sounds like from @droideveloper 's workaround that it might be worth checking changelog for kotlin 2.2.10 and/or open a youtrack explaining what changed it might be a bug.

[jhansche]

It appears that this happens when iterating kotlin.sourceSets, and taking the source files from each (setSource(sourceSet.kotlin.sourceDirectories)). Those source sets may be modified by other plugins (i.e. Apollo GQL codegen, KSP codegen, etc) in order to include their own generated sources for compilation. If a fileTree() is added, which is also configured to use builtBy(Task), then when the ktlint task resolves those sources, it also resolves the fileTree, which implicitly adds that builtBy task to the task graph as a task dependency.

As a result, even if the entire fileTree would otherwise be filtered by an exclusion (build/generated), the task dependency is still applied.

Normally that shouldn't result in triggering a full compilation, but if it's running for example *OverJvmTestSourceSet, it'll pull in kspTestKotlinJvm, which then pulls in jvmMainClasses and everything else that includes, including compiling dependency modules as well. Not to mention if you're using a DI library that's implemented using KSP, it could lead to very heavy KSP tasks, because it will be processing your entire DI graph, just so that ktlint can analyze your source files.

You can see this easily with:

  tasks.withType<BaseKtLintCheckTask> {
    doFirst {
      this@withType.source.buildDependencies.getDependencies(this).forEach {
        println("XXX ktlint source dep $it")
      }
      // translates implicitly to:
      this.taskDependencies.getDependencies(this).forEach {
        println("XXX ktlint task dep $it")
      }
    }
  }

This also explains why some people have been forced (with no explanation) to add hacks like what OP shows in the initial comment ☝️ :

        project.afterEvaluate {
            // WRONG: do not do this
            tasks.named("runKtlintCheckOverCommonMainSourceSet") {
                dependsOn("kspCommonMainKotlinMetadata")
            }
            tasks.named("runKtlintFormatOverCommonMainSourceSet") {
                dependsOn("kspCommonMainKotlinMetadata")
            }
        }

---

Without spending a lot of time on it, and recognizing that this probably won't handle all cases for all people, this is a simple way that I was able to sever the TaskDependency connection on just the Ktlint tasks:

  afterEvaluate {
    tasks.withType<BaseKtLintCheckTask> {
      setSource(source.asFileTree.files)
    }
  }