A modern programming language that makes developers happier.

kotlinlang

Hey! I’m curious what the fastest way would be to run ktlint (as pre-push/commit script) in order to keep the “dev flow” interruption as short as possible. Am I right assuming that running it as a standalone tool would be the fastest approach?
I feel like running this as a gradle task takes too much time due to gradle’s `configuration`tasks etc.

that’s an interesting question. i think the gradle plugins may take advantage of caching, so it wouldn’t need to run on files that haven’t changed

if you only run it on changed files, it should be quite fast, standalone

yeah, using the pre-commit command that just runs on the staged files, so I assume generally that there is just a few files to check. Thinking of checking in the ktlint jar directly in order to let everyone in the team using the same version.
thanks for your thoughts!

How have you included this in your work flow?

similar to yours. we use the phabricator suite of tools, and the `arc` tool has a way to invoke linters. we just use the `ktlint` executable jar and run it on the changed files.

Could speak about Gradle part as a developer of `ktlint-gradle`  plugin.

It has a task to install pre-commit hook that runs ktlint only on files included into commit. There are two hooks - either just check this files and fail commit or try to format them before committing.

Indeed Gradle configuration phase is not fast, but recently they introduce configuration cache feature (that plugin supports). This feature is greatly increasing speed of this phase.

Additionally I would advice to run ktlint-gradle on your CI pipeline to ensure non-complaint code hasn't been added into codebase.

Generally plugin supports:
• Gradle caching. So, if you have  remote build cache, check could be skipped if input sources are not changed and remote cache has entry for current input sources state.
• Incremental check. It could check only changed files.