Happy to contribute to the compiler plugin. I thin...
# detekt
t
Happy to contribute to the compiler plugin. I think one of the important features is autocorrect. But I can’t imagine changing the source files during compile is allowed (or even a good idea?). Currently my solution is to load both plugins and rename the gradle extensions in the compiler plugin so they do not conflict. Then run the detekt task from
io.gitlab.arturbosch.detekt
with auto correct before the build. Should be fine because I don’t think any type resolution rules have auto correct? I have a very rough POC doing this now. Any feedback on this approach?
g
The way how we envisioned this was for the 2 plugins to be mutually exclusive actually 🤔
t
Did you have anything else in mind for auto correct in the compiler plugin?
I have some things in mind to get them to use the same extension name. Which would at least keep the config the same, if that helps move in the direction of being mutually exclusive
s
Thanks for contributing to the compiler plugin! What exactly are you trying with the compiler plugin? @Tim Oltjenbruns It would be interesting how you want to enhance the compiler plugin.
t
@schalkms I am looking at a couple things so far. • Autocorrect • Baseline • Configurable Detekt version? Can't remember if this is already supported or not off the top of my head. I have baseline working pretty well, but autocorrect seems tricky. The compiler can't modify files, they're read only. • The corrections could be staged and applied after the compile. (Sounds complicated) • Or because I don't think any type resolution rules currently have auto correct, a simpler and short term solution could be to run the main Detekt plugin with autocorrect before compile. To get both plugins working at the same time: • I already have a PR on the main plugin to fix the resource conflict • I'll need to do a similar fix to the compiler plugin • Handle Gradle extension conflict. My POC has the Gradle extension conflict resolved by changing the name of one, but I don't think that's a great design to go forward with. Ideally, both plugins could depend on a shared artifact that contained the Gradle extension model. Whatever plugin loads first can apply the extension, and whatever one comes second can just use the same extension without loading up a conflict.