Hey! I’m curious what the fastest way would be to ...
# ktlint
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
tool has a way to invoke linters. we just use the
executable jar and run it on the changed files.
🙏 1
Could speak about Gradle part as a developer of
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.