https://kotlinlang.org logo
Join SlackCommunities
Powered by
<@U01681FLZC2> last year you contributed an <.edit...
# github-workflows-kt
p
@Adam S last year you contributed an .editorconfig for github-workflows-kt. I generally like the concept, but from then on there have been problems with star imports. Even if I have my IntelliJ configured to not use them, they are still placed, especially when I add usage of another class/function for a given package, then the star import kicks in. It's contrary to the ktlint configuration we have, which gives us contradicting settings (IDE produces code invalid for the linter). @Ben Keil is getting furious about it when starting contributing, and I admit I was too lazy to dig deeper into it. I'm wondering what's your take on this; is there some smart setting we should add? I've found some bugs on YouTrack related to this: • Editorconfig: ij_kotlin_name_count_to_use_star_import and ij_kotlin_name_count_to_use_star_import_for_members do not seem to work • Star import count settings in editorconfig file are sometimes ignored when performing reformat code - fixed in EAP version Ben suggests removing .editorconfig altogether, but then: • the IDE by default may produce code invalid for ktlint • for newcomers, they will have to configure their IDE so this option is not perfect here. Before we go forward with this, I'd like to ensure that we're not missing something
v
Is ktlint not following the official Kotlin coding conventions? Because IntelliJ should by default follow it. And for a Gradle project you also was able to specify that the official code style should be used using a Gradle property. I assume this is also still in place.
p
what do the official Kotlin coding conventions have to say about the imports? I cannot find any mention here: https://kotlinlang.org/docs/coding-conventions.html
v
Oh. Hm. :-/
Thought it does
p
still, IMO this inconsistency should be addressed somehow by the Kotlin, IntelliJ and/or ktlint (the most popular linter, de facto standard) folks
a
Do you have an example of what problems you’ve had with star imports? EditorConfig is nice because it’s IDE independent. But just committing the IntelliJ code style works too (
.idea/codeStyles/
). I’m not a big fan of ktlint and those sort of strict formatters. I find they’re overly pedantic and strict and just get in the way or interrupt the flow, so I haven’t used them.
you could try exporting the IntelliJ code style you’d like to use to EditorConfig format, or try adding these lines to EditorConfig
Copy code
ij_kotlin_name_count_to_use_star_import = 9999
ij_kotlin_name_count_to_use_star_import_for_members = 9999
p
EditorConfig is nice because it’s IDE independent.
especially the 
ij_
properties 😅 but yeah, the overall idea is that it should be IDE-agnostic we have a conflict of approaches: “IDE takes care of formatting, and it’s not checked by CI” vs. “formatting is enforced by CI, and IDE should produce code that complies with the rules” personally I’m in favor of the second approach because I want to save time or PR reviews (not care about style too much)
b
We could add a pre commit hook that formates the code, or checks If it is proper formatted. So it doesn’t matter what you do in the idea, in the end it’s always the same. At the moment it’s SUPER annoying to write code. It always ads the star imports and in the end you need to figure out the original imports
p
Can Ktlint fix the undesired star imports?
If it was possible, you could do it right now even without the hook right? Or CI could do it, or an IntelliJ plugin. I'm fairly sure it's not possible right now, and it would be really nice to have it, but I suppose it's not easy because the compiler would have to be used to resolve imported symbols into concrete names. Working on the AST is not enough here
b
At least not in the IDE. But you could configure your ide to not use stars.
How many contributers do we have?
maybe this helps?
v
A pre-commit hook also is not super helpful, as everyone would need to set up the hook manually in their local clone. For me IntelliJ never imports start imports but always does single-class imports, but that's because I hate star imports and have IntelliJ always configured to avoid them.
b
there are gradle plugins that do it for you.
the editorconfig overrides what you have configured in the kotlin code style.
v
Just that the editorconfig does not define the star-import behavior for this project currently. 🙂 Besides that I also had some quirks with IntelliJ not considering everything in editor config in the past.
b
then we are back to just remove it
p
I’m looking for a generic, convenient solution that I can apply also in other projects, not only here. Let’s see if there’s any response on the #intellij and #ktlint channels. Every approach has it pros and cons, I’d like to clarify what’s the general recommendation.
v
At least the 
ktlint
IntelliJ plugin is marked as required for the project. So everytime you open the project you get a warning that the plugin is missing. If someone ignores that, he still does not get the plugin. But the 
lintKotlin...
task for the ktlint Gradle plugin is also wired to the 
check
task, so at least if a contributor runs 
gw check
locally, he would get a failing check and could also use 
formatKotlin...
tasks to fix up the formatting.
p
could also use 
formatKotlin...
tasks to fix up the formatting.
again, star imports aren’t automatically fixable (unless you’re describing a desired state)
v
I thought the desired state is to not use start imports and that ktlint also enforces that? But it seems ktlint by default allows them to stay in sync with default IntelliJ behavior but enforces no start imports if configured with 
ij_kotlin_packages_to_use_import_on_demand = unset
in editor config: https://pinterest.github.io/ktlint/0.49.1/rules/standard/#no-wildcard-imports
p
that looks like what we need ☝️ @Ben Keil could you give it a shot whenever convenient?
v
While actually, for me 
library:lintKotlinMain
fails with a star-import even without that editorconfig setting, so 🤷
p
there’s so much ambiguity in this problem. Looks like a project on its own to untangle this in the Kotlin ecosystem
v
Also, that settings does not change IntelliJ behavior for me. But if add
Copy code
ij_kotlin_packages_to_use_import_on_demand = unset
ij_kotlin_name_count_to_use_star_import = 9999
ij_kotlin_name_count_to_use_star_import_for_members = 9999
to editor config, IntelliJ also properly uses no start imports and then is consistent with the ktlint check.
So that's probably what we want
What IntelliJ is producing if you select in the UI "Use single name import" for both options and tell it to export to editor config file is
Copy code
ij_kotlin_packages_to_use_import_on_demand = unset
ij_kotlin_name_count_to_use_star_import = 2147483647
ij_kotlin_name_count_to_use_star_import_for_members = 2147483647
p
thanks! will try it
works - @Ben Keil if you confirm this is the way to go for you, I’ll edit the editorconfig
Screen Recording 2023-05-15 at 14.45.50.mov
b
to update the editor config? works for me
p
p
Cool that you already found 
ij_kotlin_packages_to_use_import_on_demand = unset
in editor config: https://pinterest.github.io/ktlint/0.49.1/rules/standard/#no-wildcard-imports
which I also wanted to report here. In addition to that it would be best to also minimise the 
.idea/codeStyles/*
configuration as described on https://pinterest.github.io/ktlint/0.49.1/rules/configuration-intellij-idea/
2 Views
Open in Slack
PreviousNext
Powered by