You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Spotless lets you do that, although it takes a fair bit of custom configuration on your part.
Do you have any examples of prior art or APIs that might be useful in this custom configuration? In particular if there's something better than the IDE hook and iterating over files one at a time (which I suspect would be kinda slow because of gradle overhead) I'd love to hear about it!
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. ThespotlessApply
(orspotlessKotlinApply
) task, however, runs on the per-project basis. This means you could still encounter the same problem: make broken-syntax changes to thetest
sourceset, make a compilable change to themain
sourceset, and then compile themain
sourceset - this will compilemain
, then run the "finalizer"spotlessApply
, which will fail on thetest
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 withspotlessApplyMain
and finalizecompileTestKotlin
withspotlessApplyTest
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.
The text was updated successfully, but these errors were encountered: