-
-
Notifications
You must be signed in to change notification settings - Fork 766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable binary compatibility validator for detekt-test and detekt-test-api #4157
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4157 +/- ##
=========================================
Coverage 83.44% 83.44%
Complexity 3177 3177
=========================================
Files 465 465
Lines 9104 9104
Branches 1775 1775
=========================================
Hits 7597 7597
Misses 572 572
Partials 935 935
Continue to review full report at Codecov.
|
detekt-test/api/detekt-test.api
Outdated
public static final fun lint (Lio/gitlab/arturbosch/detekt/api/internal/BaseRule;Ljava/lang/String;)Ljava/util/List; | ||
public static final fun lint (Lio/gitlab/arturbosch/detekt/api/internal/BaseRule;Ljava/nio/file/Path;)Ljava/util/List; | ||
public static final fun lint (Lio/gitlab/arturbosch/detekt/api/internal/BaseRule;Lorg/jetbrains/kotlin/psi/KtFile;)Ljava/util/List; | ||
public static final fun lintWithContext (Lio/gitlab/arturbosch/detekt/api/internal/BaseRule;Lorg/jetbrains/kotlin/cli/jvm/compiler/KotlinCoreEnvironment;Ljava/lang/String;[Ljava/lang/String;)Ljava/util/List; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All functions in RuleExtensions
are extensions on BaseRule
which is in api.internal
package. So we have a public test API for a class that's supposed to be used internally only (at least, that's what the package names currently suggest).
Perhaps BaseRule
should be moved out of api.internal
into api
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this makes sense to me - Extension methods like BaseRule.compileAndLintWithContext
defined in RuleExtensions
are also used in https://github.com/BraisGabin/detekt-junit-rules/blob/main/src/test/kotlin/com/braisgabin/detekt/junit/TestFunctionsShouldReturnUnitTest.kt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BaseRule
is internal because no one should extend from it or use it directly. If someone provides to the core a BaseRule
directly that is not a Rule
nor MultiRule
undefined behaviours could happen. So I'm against this change. I don't think that we should move BaseRule to api
.
If we don't want to expose this in our public api we should duplicate all these extensions for Rule
and MultiRule
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BaseRule
is internal because no one should extend from it or use it directly. If someone provides to the core aBaseRule
directly that is not aRule
norMultiRule
undefined behaviours could happen. So I'm against this change. I don't think that we should move BaseRule toapi
.
I tend to disagree with this. As Rules
were modelled with inheritance, and we expect users to extend from a specific class, the whole inheritance chain has to be part of the public API. We should have instead modelled this using composition or designed it differently (say MultiRule
should have been a subclass of Rule
which would have been the top of the hierarchy).
I think that BaseRule
is effectively part of the public API and should be moved out of the .internal
. At the same time I understand that the .internal
package is the only warning we have to prevent users from subclassing from it directly. Perhaps BaseRule
and Rule
should just be refactored and merged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps BaseRule and Rule should just be refactored and merged?
I think that it's not worth it right now. If we want to expend time refactoring the rule api we should aim for 2.0.
And I agree, BaseRule is part of the public api in a transitive way.
2c4dbe5
to
3c4b161
Compare
3c4b161
to
1c6cc32
Compare
I like the idea of adding this to help us take better decissions. But, in general, I think that it's ok to break binary compatibility for the tests. |
Per discussion in #4117, detekt-test and detekt-test-api are commonly used for custom extensions like custom rules.
This PR enables binary compatibility validator so that we are more conscious about the public API changes - It does not necessarily mean we need to ensure binary compatibility but does provide necessary insights.