Replies: 18 comments 24 replies
-
I am using it, but if most stuff is natively supported in detekt I'd still be happy to just drop it. (Auto correction with ktlint is pretty great) |
Beta Was this translation helpful? Give feedback.
-
I use detekt + ktlint in all my projects separately so there was no need for using format rules of detekt. |
Beta Was this translation helpful? Give feedback.
-
We're using it since for formatting rules we prefer ktlint's auto correct capabilities (and it's super cool how detekt's IntelliJ plugin works well with that). The first point about using Spotless instead makes a lot of sense, though, and maybe we should've been doing that instead. But since we just have detekt and ktlint, it's really convenient to be able to use detekt's wrapper and not bother with anything else. I also totally understand how it can be confusing to have overlapping between rules, but I would assume anyone interested in using both detekt and ktlint should be aware about it, and I personally think detekt's docs on the formatting ruleset do a great job making that explicit (with the "This rules overlaps with..." sentences there). |
Beta Was this translation helpful? Give feedback.
-
The formatting wrapper is amazing. It allows easier customisation than ktlint natively and the IntelliJ plugin works like a charm. The formatter is the main reason we started using detekt do begin with. I would for sure be missing it. |
Beta Was this translation helpful? Give feedback.
-
If it is also affecting the IDE plugin, I use it and we as a team love it because it teaches formatting to newcomers during they write their codes. It helps a lot in PR reviews since the formattings are already filtered out with the plugin. |
Beta Was this translation helpful? Give feedback.
-
If detekt maintainers decide to drop the formatting plugin then we can ask community members or an organisation to take over.
This pain point should actually go away very soon as the next planned ktlint release is version 1.0. The 0.49.0 release notes say that there are no more breaking changes planned. |
Beta Was this translation helpful? Give feedback.
-
Would it make sense to drop the With version 1.0 and In terms of maintenance burden and single responsibility I'm wondering if the wrapper would be the better option since detekt would pass the responsibility of style fully to ktlint. The wrapper itself is just a wrapper, not a direct responsibility. In terms of using spotless there is no support for detekt afaik. Imo detekt is rather an alternative to spotless (a bundle of different rulesets to run) than just a ruleset on the same level as ktlint. The overall plugin support (being able to run different rulesets and display the result directly in the IDE) plus the autofixes (globally or per file) are the biggest value adds of detekt to me. |
Beta Was this translation helpful? Give feedback.
-
Did you consider making the Not sure about this, just throwing out an idea. 🙂 |
Beta Was this translation helpful? Give feedback.
-
A really important point to note here. This poll is to decide if we should keep maintaining this wrapper. If we decide to drop the support of the wrapper we will not remove it. We will move it to a different repository and ask for some one to take it over. We know that some people use this plugin we would try to make the transition as easy as possible. |
Beta Was this translation helpful? Give feedback.
-
Having formatting get auto corrected is one of my favorite features of detekt. I know that I could just run ktlint or something like spotless instead, but I much prefer doing everything through detekt. |
Beta Was this translation helpful? Give feedback.
-
I have the hope to get ktfmt support on detekt some day so I can drop an additional plugin. |
Beta Was this translation helpful? Give feedback.
-
We have just started using this. Because:
|
Beta Was this translation helpful? Give feedback.
-
We started using ktlint-gradle, then we adopted Detekt and were running ktlint-gradle + detekt and then finally switched to just using detekt for everything. IMO it is very beneficial to have everything in one package:
I do agree thought, that duplicate rules are a problem. I feel like detekt variant of duplicate rules is generally better than ktlint variant (more configurability, better documentation), so maybe duplicate ktlint rules could receive |
Beta Was this translation helpful? Give feedback.
-
Since I expect most Kotlin devs using Gradle, there are actually not many reliable ktlint Gradle integrations that are 1. actively maintained and 2. support Android projects. Previously we used the ktlint plugin from JLLeitschuh which wasn't catching up with ktlint updates and Gradle API changes (configuration cache etc.). Therefore the detekt ktlint wrapper was the perfect match for all our projects and we completely dropped other formatting plugins. Because of that I voted for "No, please keep it. We're using it". But if ktlint integration would just be moved into a separate repo and could be easily integrated like e.g. compose-rules than I would also welcome it (should make no difference for consumers). This would even allow using ktlint updates without waiting for detekt releases, right? If this is the case, than maybe the poll is a bit misleading. |
Beta Was this translation helpful? Give feedback.
-
IMO it makes no sense to keep ktlint in detekt. they're two different tools and (although convenient) I can make the same case about it being convenient for the detekt team to add ktfmt (which has some pros over ktlint). keep the library focussed IMO and make it easier for other people to understand (my team gets confused with why detekt does formatting if its a static code analyzer) |
Beta Was this translation helpful? Give feedback.
-
My vote lies somewhere between:
My vote would be:
The problem is that since ktlint is integrated into detekt, when we run into issues users naturally report them against detekt -- as end-users, we don't always know or care that another library is performing some of the function of the library we are using. Furthermore, we can run into issues like #6615 in which the detekt team says: "that's not our issue, that's ktlint, report it there", and then the ktlint team says "we can't reproduce it with ktlint, and we know nothing about detekt, so bugger off" (pinterest/ktlint#2351 (comment)). I'd rather just use ktlint directly so I am aware as a consumer of what I am using, and I can intelligently debug two simple and independent things and know straight-away where an issue lies, rather than one complected thing where the boundaries and responsibilities for issues are unclear -- is it detekt, is it ktlint, or is it the integration between detekt and ktlint? Either that, or the detekt team takes responsibility for its dependencies and deals with reports directly, and itself takes on the responsibility of reporting issues upstream when indeed the problem is upstream. |
Beta Was this translation helpful? Give feedback.
-
Reading through this discussion, I did not see any mention of performance. I have some questions:
|
Beta Was this translation helpful? Give feedback.
-
How hard would it be to extend Detekt's style rules so that it covers everything that KtLint covers? Also, to add support for auto-fixing those style rules? My main problem with KtLint is that it's not configurable (you can only disable rules), and I don't like the direction it's going. I'm not looking for deterministic formatting like It's a shame that Kotlin doesn't have a configurable auto-format linter. Since Detekt is configurable and already supports some style rules, maybe it's not far from becoming that? Then, to answer the poll question, Detekt can shed the KtLint wrapper and steer users to its own native formatting features instead. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I'm opening this poll to ask the community whether we should remove the support for
detekt-formatting
or not.The detekt
formatting
ruleset is a first party collection of rule we maintain that effectively wraps KtLint (see https://detekt.dev/docs/rules/formatting/).It's shipped as a separate artifact that developers have to include it with a
detektPlugins
dependency: https://detekt.dev/docs/introduction/extensions/#let-detekt-know-about-your-extensionsThis ruleset has always been controversial for a number of reasons:
style
that provide the same functionalities as the equivalentformatting
rules, likeWildcardImport
vsNoWildcardImports
orUnusedImports
vsNoUnusedImports
. This is confusing for users as they don't immediately understand why they do have two similar rule in the config files.formatting
ruleset due to how KtLint exposes reporting information (fixed in 1.23.x Add support for local suppression inside formatting #5876 though).We're going to publish a
detekt-formatting
artifact for 1.23.x, but we're wondering if this is used and also how (like what's your use case). If there are no meaningful use cases, we'll probably consider dropping it.So please vote to this poll + share your concerns and use case.
186 votes ·
Beta Was this translation helpful? Give feedback.
All reactions