# sborka

> Gradle conventions as a plugin, and kapkan beside them: ktlint rules that each encode one defect the stack paid for, with no configuration and suppressions that have to say why.

Page: https://kotlin.website/sborka

## Why it exists

Nineteen Gradle builds had arrived at five ways of publishing, four wirings of ktlint and eleven
different `.editorconfig` files. sborka is one plugin that settles those — the coordinate, the
toolchain, publishing, the formatter, the test gate — and one line in `gradle.properties` instead of
dozens of lines of Kotlin per repository.

**kapkan** is the second half: a ktlint rule set the conventions hand to ktlint, where each rule
encodes one class of defect found in this stack rather than an opinion about style.

## One line per decision

```properties
sborka.group=io.github.youndie
sborka.jvmToolchain=25
sborka.jvmFloor=25
sborka.junitVersion=6.1.3
```

## The gate that reads the results

`sborka.test` compares the `@Test` methods a module declares with what JUnit reported. A test whose
last expression returns a value is not a test — JUnit does not run it and does not warn — and three
of them were found this way in one repository, two months old, one covering a defect that could zero
a subscriber's remaining allowance.

Native and browser suites get the smaller half of the same question: a suite that ran nothing does
not pass.

## What kapkan catches

Three ktlint rules, each with the item it was found in — a platform's own package imported into
common code, a failure nothing reads, code asking the machine it happens to run on what time it is —
plus a guard that makes every suppression say why, and `kapkanJoins`: the declarations nothing
outside their own file mentions and the functions nothing calls.

There is no configuration. A rule is in the set or it is not, and the only knob is a suppression that
has to say why.