Is there any issue with running <ktlint-grade> on ...
# ktlint
s
Is there any issue with running ktlint-grade on an
com.android.library
module? I’ve got a simple module which is setup to be a com.android.library and also applies this ktlint setup. However in the end, in the files that are contained in this core-common module things do not get formatted at all.
:core-common:ktlintCheck
doesn’t find an error and ktlintFormat doesn’t edit them at all either. It’s weird because I do the exact same setup on my app module which is a com.android.application instead and it works perfectly fine. I’ve also tried stuff like applying the plugin only to that one module but still nothing, it only works on my application module. If anyone else who’s using the plugin in a multi-module setup like this has any ideas I would really appreciate it. (.editorconfig used is here and I am using ktlint gradle plugin 10.3.0 with ktlint “0.45.2”)
m
I'd guess you hit: https://github.com/JLLeitschuh/ktlint-gradle/issues/524 - you should find more details in the issue :)
Although, I wouldn't recommend applying the workaround pasted there 👀 you should rather modify ktlint-gradle tasks sources, not altering AGP config. I don't know if it breaks abythinh, but I'd assume they introduced a separate sourceset for a reason 🤷‍♂️
s
Oh wow that’s an odd one. By modifying the ktlint-gradle task sources you mean forking the project and altering the internals of it? I’d rather not do that right now at least 😅 I’d rather simply change to /java as sources since that’s merely an aesthetic change as far as I am concerned.
And it works, just changed them all to java. Thank you so much I was going insane trying to figure out what I was doing wrong 😅 You came in clutch
😄 1
m
By modifying the ktlint-gradle task sources you mean forking the project and altering the internals of it?
no, I meant doing something like (pseudocode)
Copy code
tasks.named("nameOfKtlintTaskForMainSourceset") {
   sources += android.sourceSets.main.kotlin.srcDirs
}
If you considered using a fork you can simply use the one from: https://github.com/JLLeitschuh/ktlint-gradle/pull/558 🙂
I’d rather simply change to /java as sources since that’s merely an aesthetic change as far as I am concerned.
I recall having mixed Kotlin & Java sources comes with performance penalty. I haven’t seen AGP’s release notes, but I bravely assume (and hope 😅) they introduced a separate bucket for Kotlin sources to improve build performance. This might not be the case (yet?) but if it was, keeping Kotlin sources under
/java
directory might not be something one would want (all of this are my personal thoughts, I don’t have any release notes nor issuetracker links to back it up, you might be all good with just
/java
🙂)
And just in case: if you haven’t seen yet: https://github.com/JLLeitschuh/ktlint-gradle/issues/569 + I can totally recommend: https://thebakery.dev/35/ which provides even more insights on the current state of ktlint-gradle 🙂
p
We have greatly simplified our process by checking in the ktlint binary using git lfs. No more Gradle plugin problems and blazingly fast git hooks that take milliseconds instead of waiting for the gradle configuration phase to complete.
s
no, I meant doing something like (pseudocode)
Ah of course, might give it a try!
mixed Kotlin & Java sources comes with performance penalty
Yeah your assumption does make sense. Our codebase is 100% Kotlin, and for now I could just go with all java. I would hope if it has any effect it will have a negligible one so I am willing to take the risk there 😄
And just in case: if you haven’t seen yet
Awesome, this does look like something I’d enjoy listening to! I’m not commuting lately and I’ve been struggling to find the time to listen to these podcasts. What a problem to have huh 😅
😄 1
We have greatly simplified our process by checking in the ktlint binary using git lfs
That does sound very interesting. I have not touched git lfs at all so my first instinct is to avoid going that route at least for now while this isn’t a problem for us, but it does sound like a great idea. Are you aware of any source where I can read more about how I would go about doing something like that by any chance? For our case the reason I even introduced the plugin in the first place is consistency. We were manually using ktlint on our devices and the CI was doing its own thing resulting in inconsistencies sometimes whennot running the correct command making this process quite frustrating for no reason. I thought going for the gradle plugin, having everyone just run
./gradlew ktlintFormat|check
would be a great step forward to not have to think about it again at all. Plus our old github action was taking >4 minutes with most of the time spend building ktlint from source while the new one takes <2 minutes. I guess with your idea of using git lfs it’d be even faster right.
Also as I see it now, very interesting that both ktlint-gradle and kotlinter exist. They seem like they solve the exact same problem. Out of pure curiosity, what is the reason for that? Since you’re one of contributors there you might know more of the lore 📜
m
what is the reason for that?
To be honest, I don’t know 😛 kotlinter was initially more performant and I appreciated its simplicity.
ktlint-gradle
was more complex and it tried to support every use-case. I started using kotlinter for all my projects, which then evolved into contributing to pay back the community 🙂 I recently got promoted to a Collaborator, and I’m trying to keep the plugin working for the Android ecosystem (i.e. I was the author of the kotlinter fix for the same bug you encountered initially here). That’s my story 😛 Why there are two Gradle plugins? idk 🤷
s
Hehe yeah and it now makes total sense how you found the issue I had instantaneously, you have even fixed it for that plugin 😅 Alright yeah that backstory makes total sense, thanks for sharing your story 🙌