I noticed a new <kotlin-formatter >project release...

# squarelibraries

[Kim]

I noticed a new kotlin-formatter project released just this year, which seems to be a wrapper around ktfmt. I cannot find any blogposts or such regarding this, what is the motivation for this new project i.e. what issues does this project address that the current ktfmt CLI/IDE plugin cannot?

[Keith Abdulla]

I asked one of team members and they updated the readme to make that more clear. hope this helps

https://github.com/block/kotlin-formatter?tab=readme-ov-file#why-kotlin-formatter

[michaelsims]

Very interesting. My team recently switched to ktfmt, so this stuff is fresh on my mind.
So far my team has found that if we sync ktfmt versions across gradle (we're using spotless + ktfmt), CLI (via homebrew), and the IJ ktfmt plugin, they seem to produce the same behavior. IJ already supports format on save with the existing ktfmt plugin. So, no argument intended, but I more want to understand. I think all I'd get from this is the configurable max-width?
EDIT: We also have an optional pre-commit hook... we're not mandated to use it, but most devs turn it on to avoid wasting time pushing up a PR that doesn't pass ktfmt "lint"

[michaelsims]

I will admit that we have some glue scripts that had to be developed for all of this, so maybe (in addition to the configurable max-width) that's really what this project is (i.e. "glue")

[Kim]

• Configurable max-width – When we first explored ktfmt, its CLI didn’t support configuring max-width. Different projects and repositories have varying formatting standards, and we wanted to support this flexibility. In our case, we use a standard formatting width of 120 characters.

• Automated Formatting Support in Git Workflow – We wanted formatting to be automatically applied before code is committed to prevent formatting drift as early as possible, keeping it closest to the inner development loop.

• Format-on-save for IntelliJ – Format-on-save for IntelliJ – While ktfmt provides IntelliJ integration, our plugin includes format-on-save support in addition to manual formatting, reducing manual steps for developers.

• Consistent formatting experience across tools – We ensure consistency by having CLI, Gradle, and IntelliJ all use the same CLI under the hood, applying the same formatting rules across all workflows.

Seems the comparative advantage of this tool should mostly be point #4 then. For me I already apply ktfmt through pre-commit framework hook and gradle preBuild task via spotless plugin. I also frequently iterate build on Compose preview, etc so format-on-save is not a game changer for me. A quick start section or a demo project to demonstrate the last point might be useful for increased adoption and community feedback (if such is the goal)

[Sutina Wipawiwat]

👋 Hi all! I'm Tina, one of the main contributors to Kotlin Formatter. First off, thank you for the feedback! (and thanks @Keith Abdulla for letting me know about this thread)

You're right—point #4 (ensuring consistent formatting behavior across the CLI, Gradle, and IntelliJ) is one of the key advantages we're aiming for. While tools like Spotless or pre-commit hooks each address parts of the problem, we've found that subtle inconsistencies can creep in when different environments use slightly different configurations or versions of ktfmt.

By wrapping ktfmt in a single CLI that drives all our formatting touchpoints—Git hooks, Gradle tasks, and IntelliJ format-on-save—we’re making sure formatting is consistent and predictable no matter how you’re working.

We haven’t fully migrated the Gradle or Git hook integrations yet, but they’re on our roadmap. And we totally agree that a quickstart or demo project could help—we’ll definitely consider adding one to make it easier for others to try out the formatter.