Add config delegate to public api

[marschwar]

This is a part of #3670.

I was going to mark ThresholdRule and LazyRegex as deprecated but then I did not know what to suggest to users on how to replace it unless making the config property part of the public api. I think the "nicest" way is to mark the functions whith @UnstableApi but then almost all native rules would have to opt in which also seems weird.

Please let me know your opinion on how to move forward with this.

[codecov]

Codecov Report

Merging #3891 (d25b52f) into main (40abc3f) will decrease coverage by 0.00%.
The diff coverage is 97.56%.

❗ Current head d25b52f differs from pull request most recent head 3e4183f. Consider uploading reports for the commit 3e4183f to get more accurate results

@@             Coverage Diff              @@
##               main    #3891      +/-   ##
============================================
- Coverage     83.44%   83.43%   -0.01%     
  Complexity     3149     3149              
============================================
  Files           456      456              
  Lines          9014     9015       +1     
  Branches       1754     1754              
============================================
  Hits           7522     7522              
- Misses          565      566       +1     
  Partials        927      927              

Impacted Files	Coverage Δ
...otlin/io/github/detekt/custom/SpekTestDiscovery.kt	65.45% <ø> (ø)
...otlin/io/gitlab/arturbosch/detekt/api/LazyRegex.kt	0.00% <0.00%> (ø)
...n/io/gitlab/arturbosch/detekt/api/ThresholdRule.kt	0.00% <ø> (ø)
...detekt/formatting/wrappers/ArgumentListWrapping.kt	100.00% <ø> (ø)
...urbosch/detekt/formatting/wrappers/FinalNewline.kt	100.00% <ø> (ø)
...bosch/detekt/formatting/wrappers/ImportOrdering.kt	100.00% <ø> (ø)
...turbosch/detekt/formatting/wrappers/Indentation.kt	100.00% <ø> (ø)
...ch/detekt/formatting/wrappers/MaximumLineLength.kt	100.00% <ø> (ø)
...etekt/formatting/wrappers/ParameterListWrapping.kt	100.00% <ø> (ø)
...rbosch/detekt/rules/complexity/ComplexCondition.kt	88.09% <ø> (ø)
... and 65 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 40abc3f...3e4183f. Read the comment docs.

[schalkms]

Can you please elaborate on the solution?
What are the pros and cons of this solution?
For which parts of the implementation would you like to have feedback?

[marschwar]

Sorry, I should have been more specific. The questions are less about the actual implementation but rather about the general way forward.

• Should the config property delegates become part of the public api?
• Should the @Configuration become part of the public api?
• Should the new parts of the api be marked with @UnstableApi?
• Do we agree that the ThresholdRule and LazyRegeg should be marked as deprecated and will be removed with detekt 2.0?

[schalkms]

Should the config property delegates become part of the public api?
Should the @configuration become part of the public api?

I'm not sure here. Do we really want to publish those property delegates and annotations? We would then need to keep them stable as part of the API.

Should the new parts of the api be marked with @UnstableApi?

+1

Do we agree that the ThresholdRule and LazyRegeg should be marked as deprecated and will be removed with detekt 2.0?

+1

[chao2zhang]

My answers would be as follows:

• Should the config property delegates become part of the public API? - Yes
• Should the @configuration become part of the public API? - Yes
• Should the new parts of the api be marked with @UnstableApi? - Probably no, since we have migrated all detekt rules to @configuration.
• Do we agree that the ThresholdRule and LazyRegex should be marked as deprecated and will be removed with detekt 2.0? - Yes

[marschwar]

I am less sure about ActiveByDefault, @Configuration and @RequiresTypeResolution as they are only used to generate the config file and documentation. I do not see any benefit right now to expose those.

[chao2zhang]

@schalkms since you have reviewed this PR, would you mind taking another look again?

[schalkms]

@chao2zhang fine for me. Merging this PR helps to close the linked issue as well, since all TODOs are now done.👍

[schalkms]

Excuse me please, I overlooked the latest changes in this PR whilst checking my GitHub notifications.

[cortinico]

@marschwar Would you be able to write some documentation on this API (both the configuration delegate and all the new annotations) so I can add it to the release notes for 1.18.0?