# Scalafix: rewriting and linting Scala source with metaprogramming rules

> Scalafix is the Scala Center's tool for both rewriting and linting Scala code, and the interesting part is that the rules are written in Scala itself and can inspect the typed tree, so a rule can reason about types rather than matching on text. The repository is a multi-module sbt build with a CLI, a core, a testkit and a reflect module, and the user documentation lives on a separate site.

**scalacenter/scalafix** — Refactoring and linting tool for Scala

- Repository: https://github.com/scalacenter/scalafix
- Website: https://scalacenter.github.io/scalafix/
- Stars: 877 · Forks: 204
- Language: Scala
- License: BSD-3-Clause
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/scalacenter-scalafix

## Rewrite and lint from one rule format

The project describes itself in one line as a rewrite and linting tool for Scala, and those two jobs are the reason it exists rather than a formatting tool. A rewrite changes code, and a lint reports on code, and having one rule format for both means the check you wrote as a lint can become the change you apply as a rewrite. The scope is deliberately narrow and deliberately deep. It works at the level of the typed tree rather than the text, so a rule can know that a value is a String rather than guessing from how it is spelled, and the repository topics list metaprogramming, rewrite, refactoring, linter, scala, sbt and dotty, which together describe a tool that manipulates compiled Scala code rather than parsing files. The licence is BSD-3-Clause, the default branch is main, the last push was on 2026-10-12, and the most recent releases are v0.14.9 from September 2026, v0.14.8 from the week before and v0.14.7 from June, so the 0.14 line is where the work is.

## The modules tell you how the pieces fit

The repository layout is a set of sbt modules rather than a single project, and the names describe the architecture. There is scalafix-core, which is the engine, scalafix-cli, which is the command line front end, scalafix-interfaces, which holds the abstractions the rest of the system is written against, and scalafix-reflect, which is the Scala reflection layer that makes typed rules possible in the first place. Alongside those sit scalafix-rules for the rules that ship with the tool, scalafix-testkit and scalafix-tests for the test infrastructure and the suite itself, and scalafix-docs and website for the documentation, with a website directory holding the static assets and a docs directory the site is built from. The project directory holds the build definition, and there is a separate compat-metaconfig-macros module, which is a compatibility shim for the metaconfig library the rules are written in. A build.sbt at the root and a project directory are the standard sbt layout, and the presence of both a scalafix-docs module and a website directory suggests the docs are built as a separate artifact rather than only served from the site.

## Rules are written in Scala, which is the whole idea

The reason to reach for this rather than a text based linter is that a rule can be a Scala program. The rule sees the tree, and the tree carries types, so a check can ask whether a value is a collection before it complains about a missing conversion, and a rewrite can introduce a call that type checks in the position it rewrites. The repository topics name metaprogramming and dotty for exactly this reason, since the tool works on the representation the Scala compiler produces rather than on a hand written grammar of the source. The scalafix-reflect module is the part that makes this practical, and scalafix-interfaces is the part that keeps the rules decoupled from the engine. The trade is that a rule now has a compile step of its own, and the testkit is there to make writing and running such a rule a routine activity rather than an exercise in build configuration. The tool is distributed through sbt, so a rule can be applied on compile, which is what makes the rewrite part usable in a normal build rather than as a separate cleanup pass.

## Three configuration files, each for a different tool

The repository root carries configuration for three separate things, and mixing them up is a common confusion. The .scalafix.conf is the one Scalafix itself reads, and the .scalafmt.conf belongs to scalafmt, the code formatter, which is a different project and does a different job, formatting the source rather than changing its structure. The .scala-steward.conf configures scala-steward, the tool that opens pull requests to update library dependencies. The distinction is worth being explicit about, because a team that expects scalafmt to be part of Scalafix will be surprised, and the reverse is equally true, since a project can use the formatter without touching the rewriter. The .jvmopts file at the root sets the JVM options for the build, and a .git-blame-ignore-revs file is there to attribute changes in a way that keeps the history readable when a tool has rewritten a large part of the file. The AGENTS.md file at the root and the .scala-steward.conf together suggest a project with a written convention about how changes are made.

## What the repository readme does and does not tell you

The readme in this repository is short, and it is short on purpose. The user documentation lives at the site scalacenter.github.io/scalafix, and the repository readme points there with a single line, head over here. Everything a user needs, how to configure the rules, how to run them, how to write your own, is on that site rather than in the repository. What the repository does carry is the maintenance information, and it is precise about it. The current maintainers, described as the people who can merge pull requests, are listed individually with their GitHub handles, including Brice Jaglin, Gabriele Petronella, Guillaume Massé, Ólafur Páll Geirsson, Meriam Lachkar and Shane Delmore. That list is the governance of the project in four lines, and it is a much better signal of whether a project is likely to be maintained than a version number is. The contributing link points at a CONTRIBUTING file in the root, and the repository also has a CHANGELOG, a NOTICE file alongside the LICENSE, a doc directory, a bin directory and a script directory.

## Releases, a chat, and the shape of adoption

The release line is 0.14 and it is moving at a steady pace, with v0.14.9 in September 2026, v0.14.8 a week earlier and v0.14.7 in June 2026, and the badges point at a build status workflow and a Discord chat to join. There is also a latest version badge pointing at the Scala index for the scalafix-core artefact, which tells you that the core module is the one published under a coordinate that people depend on directly, and the licence is BSD-3-Clause with a NOTICE file, which is the combination you would expect from a tool that is embedded in other people's build pipelines and therefore needs a permissive licence with attribution. The build itself is sbt based, with a .scala-steward.conf to keep the dependencies moving and a CI workflow badge. The reasonable way to evaluate the project is through the documentation site, and the reasonable way to gauge whether it will still be here in a few years is to look at the maintainer list, which is short, named, and the reason the readme bothers to name them.

## Conclusion

Scalafix suits a Scala team that wants automated refactorings and custom lint rules written in the language they already use, with access to type information rather than pattern matching on source text, and it fits an sbt build where a rule can be applied as part of the normal compile cycle. It does not suit a team that wants a text-based formatter, since the transformations are semantic, and the repository itself is the project more than a distribution. Before you adopt it, read the user documentation site rather than the repository readme, which is only a pointer, and check how the maintainers currently split the work, since the named maintainers are the people who can merge changes.

## FAQ

### What is Scalafix used for?

It is a rewrite and linting tool for Scala. Rules can be written to report a problem or to change code, and they work on the typed tree rather than on the source text, so they can reason about types and produce code that type checks in the position it rewrites.

### What is the difference between the .scalafix.conf and the .scalafmt.conf files?

The .scalafix.conf configures Scalafix, and the .scalafmt.conf configures scalafmt, which is a separate code formatter. One changes the structure of the code and the other formats it, and a project can use either without the other.

### How is Scalafix built and distributed?

It is an sbt build with a build.sbt at the root and a project directory. The modules are scalafix-core for the engine, scalafix-cli for the command line, scalafix-interfaces for the abstractions, scalafix-reflect for the Scala reflection layer, scalafix-rules for the bundled rules, scalafix-testkit and scalafix-tests for testing, and scalafix-docs and website for the documentation.

### Where do I find the documentation for Scalafix?

On the site at scalacenter.github.io/scalafix, which the repository readme points to. The repository itself is short and concentrates on the maintainer list, the contributing file and the configuration files, with the theme list naming Brice Jaglin, Gabriele Petronella, Guillaume Massé, Ólafur Páll Geirsson, Meriam Lachkar and Shane Delmore as the people who can merge pull requests.

## Sources

- [License: BSD-3-Clause](https://github.com/scalacenter/scalafix/blob/main/LICENSE)
- [Project website](https://scalacenter.github.io/scalafix/)
- [README](https://github.com/scalacenter/scalafix/blob/main/README.md)
- [Releases](https://github.com/scalacenter/scalafix/releases)
- [scalacenter/scalafix on GitHub](https://github.com/scalacenter/scalafix)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scalacenter-scalafix