ktfmt
ktfmt copied to clipboard
facebook
IntelliJ/ AS-Plugin configuration via a file
IntelliJ Plugin understanding
As I understand it by looking through the code, when using the IntelliJ/ AS-Plugin there are 4 code options to be selected to re-format my code. If I were to configure the line length to 120 in the gradle plugin, the IntelliJ/ AS-Plugin would reformat differently and I would have to call ktfmtFormat by hand in order to passe the quality gate set by ktfmtCheck.
Feature Request
In order to sync the IntelliJ/ AS-Plugin with the Gradle-settings I would like to introduce a Gradle-task, which will write a File with all set settings. In turn this file can be checked in and loaded by the IntelliJ/ AS-Plugin. This will ensure that Gradle and IntelliJ/ AS will format in the same way.
If the authors of this tool see it as a beneficial addition, I would try to implement it in the Gradle and IntelliJ/ AS-Plugin.
If the authors of this tool see it as a beneficial addition, I would try to implement it in the Gradle and IntelliJ/ AS-Plugin.
Speaking from the Gradle plugin side: I'm fine with everything. I guess is more a question for @cgrushko and potentially how the tool should interact with the solutions already available in the ecosystem such as https://editorconfig.org/
I guess is more a question for @cgrushko and potentially how the tool should interact with the solutions already available in the ecosystem such as https://editorconfig.org/
I do not know how much sens it would make to somehow extract the information from an editorconfig, because this tool is already restricted to kt / kts files only and further more I do not know whether all Gradle plugin settings can be mapped to an editorconfig setting. Furthermore, when you call the Gradle task to dump out the settings, should the editorconfig be appended/ overwritten/ or somehow searched for the right place to insert the settings? In my opinion it is not an easy task and maybe we could use an abstraction to first write it to an own file and later on write an implementation, which can handle an editorconfig as a backend?
I do not know how much sens it would make to somehow extract the information from an
editorconfig
The reason why I mentioned .editorconfig is that the Gradle plugin and the IntelliJ plugin are just two consumer of ktfmt. There could be others: Bazel plugins, Maven plugins, VS Code plugins and more.
Ideally the solution here should be general purpose. Similar tools, such as ktlint, already offer .editorconfig that allows to abstract away how you can share editor configuration between different linters/formatters.
when you call the Gradle task to dump out the settings
Which gradle tasks are you referring to?
The reason why I mentioned .editorconfig is that the Gradle plugin and the IntelliJ plugin are just two consumer of ktfmt. There could be others: Bazel plugins, Maven plugins, VS Code plugins and more.
I see. It would probably make sense to use an .editorconfig file in this case, because one could check it in with bazel, whatnot configs and be sure, that IntelliJ / AS would pick it up. It could happen, that the bazel/ gradle/ whatnot-config might be out of sync with the .editorconfig. Detecting this could be tricky, but I would say it does not really matter for now.
Which gradle tasks are you referring to?
The one I introduced in my first post. I would like to create a Gradle-task, wihch will dump out the settings, which are configured in the ktfmt gradle plugin.
I'm a bit torn on this, because ktfmt is not configurable on purpose. We do support the "default" format (used internally at Facebook) and "google" format (used internally at Google and possibly others), and these are thoroughly tested and the tests maintained.
The integrations with Gradle and Maven are community-built (which is awesome) and our stance is that you're free to configure ktfmt in any way you'd like, but outside of the two supported styles, out support if best-effort.
The plugin itself doesn't get enough love anyway, because we don't use it internally at Facebook, so, I'm afraid of what I'm about to say, but we might all benefit if we take it out of the ktfmt repo into a community-driven repo.
I'm a bit torn on this, because ktfmt is not configurable on purpose. We do support the "default" format (used internally at Facebook) and "google" format (used internally at Google and possibly others), and these are thoroughly tested and the tests maintained.
Makes sense 👍 Then @SergejIsbrecht probably the safest approach for you would be to setup your own machinery to share some config, perhaps using environment variables or .properties files.
@cortinico,
setup your own machinery to share some config, perhaps using environment variables or .properties files.
I can do that, but how will the AS-Plugin know which file to load? I may as well fork the AS-Plugin, but I actually do not want to cherry-pick the changes from main-line to my fork.
I think it is quite strange that the Gradle-Plugin (max line len) is configurable but the AS-Plugin is not.
Closing as stale. Please reopen if you want to continue the discussion/request
