Styler: the Elixir formatter that rewrites your code instead of complaining

A formatter plugin that changes code, not just whitespace

Styler is an Elixir formatter plugin that goes beyond formatting by rewriting your code to optimize for consistency, readability, and performance. It is a plugin for the built in formatter, so the entry point is the command every Elixir developer already runs, and the effect is that mix format no longer only aligns things, it also changes them.

The feature list in the README is what makes the scope clear. Styler sorts and organizes import, alias, require and other module directives. It automatically creates aliases for repeatedly referenced module names, the alias lifting feature, and makes sure aliases you have defined are actually being used. It keeps lists, sigils and even arbitrary code sorted when you ask it to with the # styler:sort comment directive. It optimizes pipe chains for readability and performance. It rewrites deprecated Elixir standard library code, which the README frames as speeding adoption of new releases. And it auto fixes many Credo rules.

That last point explains the design. A linter reports; Styler fixes. The README says this means you can spend less time fighting with CI, and the whole tool exists to remove the class of review comments that are mechanical rather than substantive.

The lineage is documented too. Styler's first incarnation was as one-off scripts to rewrite an internal codebase to allow Credo rules to be turned on, powered by the Sourceror library, and while Styler no longer relies on Sourceror, its AST-Zipper implementation was forked from that project. The Credo rules and their tests were referenced when implementing the styles.

Alias lifting and the sorting of module directives

Two of the rewrites do most of the visible work, and they are related.

Directive sorting moves import, alias, require and the other module directives into a consistent order. That is the boring, high value part. In a large codebase the same dozen aliases at the top of every file, in a slightly different order each time, are a reliable source of review noise, and a formatter plugin that fixes them mechanically removes that noise permanently rather than per review.

Alias lifting goes further. When a module is referenced repeatedly under its full name, Styler creates an alias for it, and it also checks the other direction, making sure that aliases you have defined are actually being used rather than sitting unused in the header of the file. This is the kind of change that looks like noise in the first pull request and then looks like the file was always written that way.

The configuration reflects that this is the behaviour teams most want to tune. The alias_lifting_exclude option is a list of module names not to lift, and the README points to the module directive documentation for more on it. The reasoning is practical. Lifting a module into an alias can shadow a name that a macro or an import later depends on, and in a codebase with heavy macro use the safe move is to exclude the offender.

There is a second configuration key, minimum_supported_elixir_version, which is aimed at library authors. It overrides the Elixir version Styler relies on when deciding which deprecation rewrites to apply, so a library that still supports an older Elixir does not have its call sites rewritten into an API that does not exist on the versions it claims to support.

Pipe chains, deprecated calls and the sort directive

The remaining rewrites fall into three groups.

Pipe chain optimization is the one the README describes in terms of both readability and performance, and it is the rewrite most likely to change the shape of a function rather than just its cosmetics.

Deprecated standard library rewriting converts calls that have been deprecated in favour of newer APIs, which the README presents as a way to speed adoption of new Elixir releases. The mechanism is the minimum_supported_elixir_version setting, since the set of applicable rewrites depends on which version you consider current. For a library with a wide support range this matters, because a rewrite that is correct for the latest release may break the older versions you still claim to support.

The # styler:sort comment directive is the manual opt in, and it is the most interesting of the three because it is the only one where the developer decides. The directive keeps lists, sigils and even arbitrary code sorted, which is a way of treating a data literal as something whose order carries meaning. In a configuration file or a list of rules, sorted order produces a small, stable diff when one item is added, and that is exactly what you want in a file that reviewers read line by line.

The Credo overlap deserves a note as well. Because Styler auto fixes many Credo rules, running both tools means the same findings are handled in two places. The README credits Credo for coalescing the community around the style rules, and says the Credo tests and implementations were referenced when implementing the styles.

The warning: rewrites that can change behaviour

The README carries a warning section, and it is the part an evaluating engineer should read twice.

The heading is that Styler can change the behaviour of your program. The text concedes that while Styler endeavors to never purposefully create bugs, some of its rewrites can introduce them in obscure cases, and it says it goes without saying but look over any changes Styler writes before committing to main.

The example given is a case statement. A case with the clauses true and false is rewritten into an if statement. The two programs are not semantically equivalent: the case raises for any value of foo other than true or false, while the if version completes without complaint. That is a real behavioural difference in a rewrite that looks entirely reasonable.

Other named risk areas are the with statement rewrites and config file sorting, and the README adds and likely other ways, stay safe out there. The blunt conclusion is that if issues like this bother you, Styler probably isn't the tool you're looking for.

This is the honest centre of the project. A formatter plugin that only reordered things would be boring. One that rewrites semantics changes what code means, and a tool like that has to tell you about the cases where its judgement is not equivalent to yours.

Installing the plugin and the cost of the first run

Installation is two edits. First, add the dependency to mix.exs:

def deps do
  [
    {:styler, "~> 1.12", only: [:dev, :test], runtime: false},
  ]
end

The only: [:dev, :test] and runtime: false settings are the ones to copy exactly, because Styler is a development-time tool and should never end up in a release dependency list.

Then register it as a formatter plugin in .formatter.exs:

[
  plugins: [Styler]
]

From that point, running mix format also gives you Styler's rewrites.

The configuration lives in the same file:

[
  plugins: [Styler],
  styler: [
    alias_lifting_exclude: [...],
    minimum_supported_elixir_version: "..."
  ]
]

One operational note that teams should plan for. The README says to expect the first run to take some time, since Styler rewrites violations of styles and bottlenecks on disk input and output, and that subsequent formats will not take noticeably more time. That is the expected shape of the change, because the expensive part is the first pass over a codebase that has never been stylised.

What the tool will not do is give you a switch to disable individual rewrites. The README states plainly that Styler will not add configuration for ad-hoc enabling and disabling of rewrites. The workaround it offers is Quokka, a fork by Smartrent that allows fine-grained control, or forking Styler yourself. Finally, the README is explicit about the project's nature: Styler is Adobe's internal tool that they are happy to share with the world.

The two experimental refactoring mix tasks

Beyond the formatter plugin, the project ships two Mix tasks that are labelled experimental.

mix styler.remove_unused deletes unused import, alias and require nodes that generate compiler warnings. mix styler.inline_attrs inlines module attributes that have a literal value and are only referenced once, removing unnecessary indirection.

Both are the kind of change that a reviewer would approve once and then want done everywhere, and both are the kind of change that can go wrong quietly, which is presumably why they are separated from the plugin and marked experimental. The second one in particular changes how a module reads, since an attribute reference becomes its literal value, and a literal inlined into several places is a literal that now has to be edited in several places.

The release history shows when they arrived. v1.10.1 is titled with the phrase experimental refactoring tasks, dated 2026-01-12, and it is followed by v1.11.0 on 2026-03-02 and v1.12.0 on 2026-07-29.

The repository layout is small and conventional for a Mix project, with the code in lib/, the suite in test/, the documentation in docs/ including the module directive and deprecation pages the README links to, a .formatter.exs at the root for the project to style itself, a .tool-versions file, a mix.lock and a CHANGELOG.md. The package is published on Hex as styler with its documentation on HexDocs.

Where Styler is the wrong tool

The README names the cases itself, and they are specific enough to be useful.

Styler is probably not a good match for experimental, macro heavy codebases. The rewrites reason about AST shapes, and code that builds its AST at compile time is exactly the code where a static rewriting pass has the least reliable model of what the program does. The behaviour change warning in the README is the same point made from the other direction.

It is also not a fit for teams that do not care about code standards, and there is no arguing with that, since the entire value of the tool is the consistency it imposes.

The third case is a team that wants control it cannot get. There is no per rule switch, and the README explains that this is a decision rather than an oversight, pointing at Quokka or at forking. For a team with a strong opinion about one specific rewrite, that is a real constraint, and the workaround is a fork rather than a configuration.

One more practical consideration is the review burden at adoption time. Turning the plugin on against an existing codebase produces a large diff that is mechanically correct and semantically almost always right, and reviewing it line by line is expensive the first time. The README's guidance to look over changes before committing to main applies most heavily on that first run.

Editorial conclusion

Adopt Styler if you work in Elixir on a shared codebase where code review time goes into directive ordering and alias hygiene, and you are prepared to review the diff once when you turn it on. Do not adopt it in a macro heavy or experimental codebase, and do not adopt it if your team does not want a tool changing semantics of committed code. Verify three things first: that your formatter configuration and Styler do not conflict, because Styler runs inside mix format rather than beside it; whether the rewrites your codebase triggers are ones you accept, since the README warns that some can change behaviour, naming with statement rewrites and config file sorting as examples; and which rewrites you want excluded, knowing that the project has declined to add per rule enable and disable switches and points to the Quokka fork instead. The licence is Apache-2.0, the last push was on 2026-08-26, and the newest release is v1.12.0 dated 2026-07-29.

Frequently asked questions

Official sources

1. adobe/elixir-styler on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases