wakingrufus
04/27/2023, 10:12 PMSha Sha Chu
04/27/2023, 10:28 PMBaseline
. we may just need to move it back into ktlint-corewakingrufus
04/27/2023, 10:36 PMSha Sha Chu
04/27/2023, 10:51 PMwakingrufus
04/27/2023, 10:56 PMSha Sha Chu
04/27/2023, 10:59 PMwakingrufus
04/28/2023, 10:14 PMSha Sha Chu
04/28/2023, 10:26 PMwakingrufus
04/29/2023, 1:06 AMPaul Woitaschek
04/30/2023, 6:45 AMSha Sha Chu
05/01/2023, 6:03 PMwakingrufus
05/01/2023, 6:07 PMPaul Woitaschek
05/01/2023, 6:07 PMwakingrufus
05/01/2023, 6:07 PMSha Sha Chu
05/01/2023, 6:08 PMwakingrufus
05/01/2023, 6:10 PMSha Sha Chu
05/01/2023, 6:12 PMPaul Woitaschek
05/01/2023, 6:13 PMwakingrufus
05/01/2023, 6:15 PMPaul Dingemans
05/09/2023, 9:00 AMfilter the linting errors found in our various gradle custom reporters
? When using Ktlint CLI, the linting errors which are stored in the baseline.xml
are already filtered out before calling the reporters.
3. When calling KtLintRuleEngine directly, why do you want to filter out results formerly stored in the baseline of Ktlint CLI?
I would like to understand this as exposing the Baseline does not seem logical to me at this moment. Also exposing it as a separate artifact does feel a bit weird when I look at the result architecture diagram.Sha Sha Chu
05/09/2023, 4:05 PMPaul Dingemans
05/09/2023, 4:16 PMlint
and format
tasks of KtLintRuleEngine
. After filtering out all lint errors that exists in baseline.xml
the remaining lint errors are sent to the reporters.Sha Sha Chu
05/09/2023, 4:23 PMPaul Dingemans
05/09/2023, 4:25 PMwakingrufus
05/09/2023, 8:33 PMPaul Dingemans
05/10/2023, 4:19 PMbaseline.xml
as used by Ktlint CLI should be identical to the baseline that is used by the Gradle plugin. Or, is it essential because users of the Gradle Plugin also use Ktlint CLI for the same project?
From the viewpoint of segregation of concerns, I would advocate that both Ktlint CLI and the Gradle plugin use custom (independent) implementations of the Baseline.wakingrufus
05/10/2023, 8:28 PMktlint-reporter-baseline
to create the baseline. so we are delegating to that for serialization, so it would make sense to also delegate for deserialization, but for that we need the com.pinterest.ktlint.cli.api.loadBaseline
method right? doing this would make our baselines continue to be compatible with CLI. that is useful when, for example, devs are using the plugin locally, but the ci process might be invoking the cli by other meansPaul Dingemans
05/11/2023, 2:54 PMI am trying to figure this out, im still rather new to the codebase... but it seems we are using Reporter/ReporterV2 withThis is actually a very good remark and the solution to the problem. The Baseline class should move theto create the baseline.ktlint-reporter-baseline
ktlint-reporter-baseline
. As a result, both the producer and consumer of the baseline.xml
are in the same module. As both the plugin and ktlint-cli
already depend on the ktlint-reporter-baseline
it will work well for both of us. The API stays clean and logical.0.49.1
this weekend.wakingrufus
05/11/2023, 8:27 PMPaul Dingemans
05/12/2023, 3:31 PMwakingrufus
05/17/2023, 8:49 PMPaul Dingemans
05/19/2023, 5:48 PMwakingrufus
05/19/2023, 5:49 PMPaul Dingemans
05/20/2023, 8:59 AMRuleId
and RuleSetId
lead to Java interoperability problem in Spotless. This problem will be solved by replacing the value classes by data classes. Technically, this is a breaking change (0.50.x
). I would guess, that the impact for ktlint-gradle
is a simple recompilation. But releasing in 0.50.x
would mean an additional layer of incompatibility that you might want to avoid by skipping the 0.49.x
.
For a normal user, e.g. a non-API consumer, a 0.50.x
does not make sense at it contains no functional improvements and only a few bugfixes. For Spotless the 0.50.x
release is not pressing as they can work around the problem with reflection but want to get rid of that.
From a ktlint perspective, I would prefer to add some functional changes and then release 0.50.x
somewhere late in June. But, I can also imagine that from ktlint-gradle
perspective a 0.49.2
release would be preferred although a patch release should not be used for a breaking change. What would your preference be from the ktlint-gradle
perspective?
Then there is another noteworthy issue #1981 about a deprecation in the upcoming Kotlin 1.9 version which will cause some rules to break. To assist API Consumers in finding those problems before the actual release, I have created a fix that allows you to disable the registration of the offending extension point to find all problems and mitigate them ahead in time. This issue does not necessarily need to be released immediately, because the snapshot version can be used (after merge #2044) to analyse if detekt rules require to be changed.wakingrufus
05/21/2023, 5:55 PMPaul Dingemans
05/21/2023, 6:46 PM0.49.x
release.