Keep your code spotless
5.5k
Stars
541
Forks
261
Open issues
30
Contributors
AI Analysis
Spotless is a code formatter aggregator that unifies formatting across multiple languages (Java, Kotlin, Python, JavaScript, SQL, etc.) and build systems (Gradle, Maven, SBT). It excels at enforcing consistent code style in polyglot projects by composing different formatters into a single workflow. Best suited for teams maintaining large codebases with mixed technologies who need centralized formatting enforcement; less relevant for single-language projects or those already standardized on a ...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Spotless: a build-integrated code formatting enforcer for Java, Kotlin, and 25+ languages
Spotless is a Gradle/Maven/SBT plugin that enforces code formatting as part of the build lifecycle. It acts as a wrapper around existing formatters (Google Java Format, ktlint, Prettier, clang-format, etc.), composing them into a single `check`/`apply` workflow with added guarantees around idempotency, encoding, line endings, and git-ratcheting. Its primary audience is JVM-ecosystem teams — Java, Kotlin, Groovy, Scala — who want formatting enforced in CI without adopting a separate pre-commit toolchain. The project has accumulated over 5,500 GitHub stars and sees regular maintenance activity.
Created in April 2015 by DiffPlug, Spotless predates most modern polyglot formatting toolchains. It grew alongside the Gradle ecosystem and expanded formatter support over roughly a decade, adding Maven and SBT integrations as secondary targets.
Growth has been steady rather than explosive, driven by Gradle's dominance in Android/JVM projects and the industry-wide shift toward enforced formatting in CI pipelines. The 9 stars gained in the last 7 days suggests slow, organic discovery rather than a viral moment — consistent with a mature utility tool. ktlint adoption in the Android ecosystem likely brought Spotless along as its recommended enforcement wrapper.
Spotless is referenced in official Kotlin/Android documentation as the standard way to enforce ktlint via Gradle. It is listed in numerous open-source JVM projects' build files. The 536 forks and 5,528 stars, combined with its age and Gradle Plugin Portal presence, indicate meaningful real-world usage. Exact download/usage metrics from the Gradle Plugin Portal are not surfaced here, but adoption in the JVM build tooling space appears substantial rather than token.
Appears to follow a plugin-core separation: a language-agnostic `lib` and `lib-extra` core defines formatting steps as composable `Function<String, String>` units, while `plugin-gradle` and `plugin-maven` provide build-system-specific wiring. This design likely allows formatters to be added without touching build-system code. Idempotency enforcement via a 'padded cell' mechanism is explicitly documented, suggesting defensive engineering around a known real-world failure mode.
Not explicitly documented in README, but the README references specific test files by path (e.g., `EncodingErrorMsgTest.java`) and mentions an idempotency test infrastructure (`PADDEDCELL.md`), suggesting a meaningful test suite exists. Actual coverage metrics are not disclosed.
Last push was 2026-06-21, six days before the evaluation date — actively maintained. The project has been under continuous development for over 11 years, with Gradle and Maven plugin versions tracked separately via badge links. No signs of stagnation; the cadence appears regular and deliberate.
ADOPT IF: you run a JVM-ecosystem project (Java, Kotlin, Groovy, Scala) with Gradle or Maven and want formatting enforced in CI with minimal custom scripting. AVOID IF: your stack is primarily JavaScript/TypeScript/Python with no Gradle/Maven build — the overhead of a JVM build plugin is unjustified. MONITOR IF: you are evaluating whether to consolidate formatting enforcement across polyglot monorepos, where Spotless' language coverage is broad but its build-system coupling may be a constraint.
Independent dimensions
Mainstream potential
5/10
Technical importance
7/10
Adoption evidence
7/10
- Build-system coupling means Spotless is tightly bound to Gradle/Maven versioning cycles; major Gradle API changes have historically required Spotless updates and can introduce lag.
- Formatter version management is delegated to Spotless configuration — pinning formatter versions correctly is the user's responsibility, and mismatches can cause CI inconsistencies across machines.
- The SBT plugin is externally maintained (moznion/sbt-spotless) and appears to have lower feature parity, creating a fragmented experience for Scala teams.
- For non-JVM languages included in Spotless (Python, Shell, etc.), teams may find dedicated linters with native CI integrations more ergonomic than routing through a Java build plugin.
- Single maintainer organization (DiffPlug) — bus factor risk is non-trivial for a project with this level of ecosystem dependency, though the 11-year track record partially mitigates this concern.
Spotless will likely remain the default formatting enforcement layer for Gradle-based JVM projects for the foreseeable future. Growth will remain slow and organic — it is a utility with a defined scope, not a platform seeking expansion.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Java
- License
- Apache-2.0
- Last updated
- 2w ago
- Created
- 136mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
GradleException when multiple goals leave behind spotless-clean dir
Add support for the prince-of-space Java formatter
Document "spotless.apply.skip" and "spotless.skip" in README
Regression in 8.6.0: groovyGradle/greclipse fails with "roundtripStateInternal or equalityStateInternal should be non-null" during input fingerprinting
Open pull requests
Similar repos
beautifier/js-beautify
JS Beautifier reformats and re-indents JavaScript, HTML, and CSS code; unpacks...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
diffplug/spotless
this
|
5.5k | +5 | Java | 8/10 | 2w ago |
 jhipster/prettier-java
|
1.2k | — | Java | 7/10 | 7d ago |
 spotbugs/spotbugs
|
3.9k | — | Java | 8/10 | 2d ago |
 dprint/dprint
|
4k | — | Rust | 8/10 | 2w ago |
|
beautifier/js-beautify
|
9k | — | JavaScript | 7/10 | 4d ago |
 uncrustify/uncrustify
|
3.1k | — | C++ | 7/10 | 21h ago |
Prettier is the dominant formatter for JavaScript/TypeScript ecosystems and can be invoked by Spotless as a step. They are not direct competitors — Spotless is a build-system integration layer, Prettier is a formatter engine. Teams using both are combining them, not choosing between them.
ktlint is a Kotlin linter/formatter that Spotless wraps. Running ktlint standalone requires custom CI scripting for check/apply behavior; Spotless provides that scaffolding out of the box for Gradle/Maven projects. ktlint and Spotless are complementary.
Checkstyle focuses on style rule violations (reporting) rather than auto-fixing. Spotless focuses on format enforcement with auto-apply. They overlap in Java style checking but differ in philosophy — Checkstyle is a linter, Spotless is a formatter enforcer.
Pre-commit hooks and tools like Trunk enforce formatting outside the build system, typically in developer workflows. Spotless enforces inside the build, making it CI-first. Teams may use both, but Spotless is specifically valuable when a Maven/Gradle build is the canonical CI artifact.
EditorConfig provides per-editor formatting hints but offers no CI enforcement. Spotless fills the gap between developer-local IDE settings and build-time verification, making it complementary rather than competing.
Spotless: Keep your code spotless
