I'm new to spotless and I might miss something. However, I'm not able to disable a specific ktlint rule.
// id("com.diffplug.gradle.spotless") version "3.24.2"
spotless {
kotlin {
ktlint().userData(mapOf("disabled_rules" to "comment-spacing"))
}
}
regarding to this and that, "comment-spacing" should be disabled globally. However, I still as the following error:
$ gw spotlessCheck
> Task :spotlessKotlin FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':spotlessKotlin'.
> The following files had format violations:
src/compatTest/kotlin/io/github/gradlenexus/publishplugin/NexusPublishPluginTests.kt
@@ -48,7 +48,7 @@
import路java.nio.file.Files
import路java.nio.file.Path
-@Suppress("FunctionName")路//TODO:路How路to路suppress路"kotlin:S100"路from路SonarLint?
+@Suppress("FunctionName")路//路TODO:路How路to路suppress路"kotlin:S100"路from路SonarLint?
@ExtendWith(WiremockResolver::class)
class路NexusPublishPluginTests路{
Run 'gradlew spotlessApply' to fix these violations.
which suggests that rule is still taken into account.
What have I missed? How to effectively disable ktlint rule for the whole project?
I don't think such a disable rule exist. The mechanism in Spotless works in general though:
spotless {
kotlin {
target("*/src/**/*.kt")
ktlint("0.35.0").userData(mapOf("disabled_rules" to "no-wildcard-imports"))
}
}
Thanks for your reply. It caused that I tried to use never spotless plugin and with 3.25.0 my construction works out of the box. It seems that "something" has been fixed/implemented in the meantime.
Spotless still ignores disabled rules
[*.{kt,kts,xml}]
indent_style = space
indent_size = 4
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true
[*.{kt,kts}]
max_line_length = 165
disabled_rules = import-ordering
This configuration still causes it to nitpick on import ordering
@sp00ne it's the difference between .editorconfig versus passing explicitly through Spotless using ktlint("0.35.0").userData(
I see, but shouldn't it honor the .editorconfig anyhow? 馃 This feels highly cumbersome. Especially with sending a version name, feels like it is in a high risk zone of getting outdated upon a version bump. Or am I missing something?
The version is optional, if you leave it off you get the latest, I was just copying example above. We don鈥檛 support editorconfig, the issue which outlines how to add support for it is #162. If you pass the contents of editorconfig as userData, that will work, but it is errorprone. Would def be great if we supported editorconfig, would love to merge a PR for it!
We don鈥檛 support editorconfig, the issue which outlines how to add support for it is #162.
@nedtwigg Did you mean to refer to #142, by any chance? :)
Most helpful comment
@nedtwigg Did you mean to refer to #142, by any chance? :)