Description
The below is inspired specifically by using the ktfmt/ktlint formatters on kotlin code in a gradle project, but perhaps applies to other languages/tools too.
When running spotless before compile, there is a chance that it runs on uncompilable code (because the author has syntax errors or whatever). In such cases, the compiler error messages may be obscured by spotless tool failures. ktlint in particular has pretty bad error messages when it encounters code with syntax errors. This makes it hard to resolve the syntax errors.
A better approach is to use finalizedBy to run spotless linting after compile. This still ensures the code is linted as it is being written, but without obscuring compiler errors. However, in gradle, compilation runs on a per-sourceset basis. That is, a gradle project may have multiple sourcesets (main, test, etc.) and each one has its own compilation task. The spotlessApply (or spotlessKotlinApply) task, however, runs on the per-project basis. This means you could still encounter the same problem: make broken-syntax changes to the test sourceset, make a compilable change to the main sourceset, and then compile the main sourceset - this will compile main, then run the "finalizer" spotlessApply, which will fail on the test code.
One way to resolve this would be to introduce tasks that run on a per-sourceset basis. So then we could do things like finalize the compileKotlin task with spotlessApplyMain and finalize compileTestKotlin with spotlessApplyTest and so on. There might be other ways to resolve the issue as well, I'm open to suggestions.
We could probably prove out the concept in a separate plugin that uses the "IDE hook" integration point to iterate through files in a sourceset, but it seems like it would be better if it were implemented directly in the spotless plugin.