Allow configuration of the .editorconfig file

[Kyle Wood]

I'd like to manually configure which .editorconfig file is chosen. I'd like to be able to set it, and I think all that would require is removing the internal modifier on this property.

One thing this would allow me to do is provide a generated .editorconfig file (produced by a separate task). If there's a way to do this already please let me know, but I think that change would be really nice. I can PR it as well if that would help, if this is a change you're willing to make.

[Mateusz Kwieciński]

Hey 👋 Can you elaborate more on your use case? Why the generated file isn't generated under one of "recognized" locations? Doesn't that break IDE integration?

I think all that would require is removing the internal modifier on this property.

I'm afraid it's not that simple, and it might be even impossible, as it won't be supported by ktlint soon 👀
The property you linked is used only to refresh internal ktlint caches, its value is not passed to ktlint when processing files. Furthermore, it most likely will be changed to use the API added as a fix for pinterest/ktlint#1446 (the property was marked as internal on purpose, it wasn't meant to be a public API).
Moreover, providing your own .editorconfig file location, to provide defaults, has been marked as deprecated, so if this was implemented on the plugin side we'd have to start merging .editorconfig files on our own to build a proper EditorConfigDefaults object - which then becomes a fairly complex idea 👀

Also, I feel I need to clarify the:

I'd like to manually configure which .editorconfig file is chosen

as per: https://editorconfig.org/#file-location:

EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory. A search for .editorconfig files will stop if the root filepath is reached or an EditorConfig file with root=true is found.

and that's what ktlint does as well, it merges all applicable .editorconfig files, there is no single .editorconfig file location that is single source of truth for a given file.

To summarize: before taking any further steps, I'd like to first identify the use case for overriding/including additional .editorconfig file location and I want to double-check using existing disabledRules property wouldn't be a more appropriate solution in this case.

[Jeremy Mailen]

Yeah, as @mateuszkwiecinski points out ktlint has some built in conventions, which align with the editorconfig standard, on where these files are resolved from.

Could you generate your editorconfig file to a standard location where it would normally be picked up be editorconfig aware tools such as IDEs and ktlint?

[Kyle Wood]

I suppose I could generate it there then delete it afterwards - not exactly ideal.

This design trend is really annoying to me, it should be "convention over configuration", not "convention at the expense of configuration". ktlint removing that feature seems like a bad move to me. Considering that's the only way to configure ktlint (other than simply disabling rules), that's just bad UX.

If ktlint is getting rid of that flag then yeah I can see how there's nothing this plugin can do about that.

I won't go into much detail but my use case is simple enough - the .editorconfig file is specifically and only for configuring ktlint, since no other mechanism is provided. That's why I'm not following the standard .editorconfig convention. I'm currently using ktlint directly in a JavaExec task and I'm doing exactly what I'm describing here. I wanted to be able to use a proper plugin for it, though. I think I might have to stick with my method and not upgrade ktlint anymore once they remove that flag.

[Jeremy Mailen]

Well, I guess it's worth clarifying that kotlinter-gradle does allow some properties to be configured in the gradle file, see here: https://github.com/jeremymailen/kotlinter-gradle#configuration
Which configuration properties did you need to customize?

[Jasz]

I have a similar requirement so I'll describe my use case. We have a lot of different repositories but we want all of them to share the same .editorconfig. We've setup convention plugins to share common build logic, including linting, but right now the only way to make sure the linting is actually configured consistently is to add a gradle task which generates/overwrites the .editorconfig file before linting. A better solution, imho, would be to be able to provide the config when configuring kotlinter (see spotless documentation for how it looks there). To achieve that I believe the kotlinter plugin would have to allow the users to configure the editorConfigDefaults and editorConfigOverride params of the KtLintRuleEngine class (and here's how spotless is doing it).

[Thomas Keller]

For me the issue is the execution of tasks in a multi-component build. In such an environment I naturally only want one .editorconfig in the very root project, not in each and every component build. However, depending on the calling scheme, the root .editorconfig is picked up or not.

As an example, imagine you have Kotlin code in producta/modulea/src/main/kotlin, calling

gradle :producta:modulea:lintKotlin

will do the right thing and pick up the root .editorconfig, however, using the calling scheme

gradle -p producta modulea:lintKotlin

does not pick up the file, probably because, at least with Gradle API measures, you can't know that there is a Gradle project above producta. But the calling scheme via -p <product> is quite useful, for several purposes:

1. Gradle execution is faster because not all root-included builds need to be configured before tasks run, but only those which are part of the specific Gradle build one switches to (in this case producta)
2. Abbreviating task names (lK instead of lintKotlin) as well as multi-module matching (calling lintKotlin on the root module and executing the specific task on any submodule where this task exists) is only possible in this calling scheme

So, for me it is very much needed to have some way to configure the .editorconfig path, otherwise I can really only resort to either copy files into subcomponents silently (and ignore them from VCS).

[Thomas Keller]

OK, I looked at the code how the .editorconfig files are actually found and stumbled upon findApplicableEditorConfigFiles() and when I added root = true it worked like it should for both calling schemes, even though no other .editorconfig file was present in any parent directories. Weird, but hey, it works, sorry for the noise.