additionalEditorconfigFile Property deprecation handling and its Direct Usage in getEditorConfigFiles

[vanessamj99]

Hello!

I'm exploring the ktlint-gradle plugin codebase to better understand its behavior and how to incorporate the Gradle Problems API integration.

I've notice that the additionalEditorconfigFile property in BaseKtlintCheckTask.kt is marked as deprecated:

@get:Internal
@get:Deprecated("ktlint no longer supports this parameter")
internal abstract val additionalEditorconfigFile: RegularFileProperty

and it is being used in the getEditorConfigFiles function in PluginUtil.kt:

internal fun getEditorConfigFiles(
    currentProjectDir: Path,
    additionalEditorconfigFile: RegularFileProperty
): Set<Path> {
    val result = mutableSetOf<Path>()
    searchEditorConfigFiles(
        currentProjectDir,
        result
    )

    if (additionalEditorconfigFile.isPresent) {
        result.add(
            additionalEditorconfigFile.asFile.get().toPath()
        )
    }

    return result
}

Despite being marked as deprecated with the message "ktlint no longer supports this parameter", the code still uses the property in getEditoryConfigFiles to construct a result. This creates some inconsistency and can lead to unexpected confusion for users. To improve maintainability of the plugin and clarity, what are your thoughts on removing the additionalEditorconfigFile property and the check in getEditorConfigFiles.

Thank you for your time!

-Vanessa

[wakingrufus]

Hi! Welcome to the project.
I can understand the confusion here.
I'll explain the situation:
We support using the latest version of ktlint-gradle with many different versions of the underlying ktlint tool. We dropped support for this property because the ktlint tool no longer accepts this parameter. However we still support using this plugin with older versions of ktlint which accept this parameter. Soon, we will be dropping support for ktlint < 1.x and when we do, we will clean up this deprecated API.

Also, the reason we have not used the problems API is because we still support older versions of gradle which don't have that API yet, iirc

[vanessamj99]

Thanks for the response! I see, do you know when that support will be dropped? The problems API could be a cool addition in the future similarily with a check to see if it can be used based on the gradle version.