# JuliaFormatter.jl: width-sensitive formatting for Julia code > JuliaFormatter.jl is the opinionated Julia formatter that took its cues from gofmt, refmt and black, and it comes with a jlfmt command line tool that can check, diff, reformat in place or run across a directory with multiple threads. The caution in the README is about the style options, where SciMLStyle and YASStyle are still rough in v2 while Default and Blue have been largely stable since v2.10. **JuliaEditorSupport/JuliaFormatter.jl** — An opinionated code formatter for Julia. Plot twist - the opinion is your own. - Repository: https://github.com/JuliaEditorSupport/JuliaFormatter.jl - Website: https://juliaeditorsupport.github.io/JuliaFormatter.jl/ - Stars: 646 · Forks: 82 - Language: Julia - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/juliaeditorsupport-juliaformatter-jl ## A formatter that measures lines and calls the result opinionated JuliaFormatter.jl is described as an opinionated code formatter for Julia, with the tagline that the opinion is your own, and the README describes it as a width-sensitive formatter for Julia code inspired by gofmt, refmt and black. Those three names are the design brief. gofmt is the Go tool that made formatting non-negotiable, refmt is the Reformatter that gave Julia its first widely used style, and black is the Python formatter whose line length default and reformat-everything philosophy most closely resemble what JuliaFormatter does. The width sensitivity is the point: the formatter decides where lines break rather than leaving the layout to the author, which is what makes the output stable enough to diff and to enforce in CI. The audience is a Julia team that has decided to stop arguing about layout, and the project is MIT licensed with its default branch on main. ## Which styles are settled and which are not The README carries a note block about version 2 that anyone adopting it should read before choosing a style. In JuliaFormatter v2, SciMLStyle and YASStyle still have a number of rough edges, and the note says that if you are using these styles you should consider using v1 of JuliaFormatter. Default and Blue styles, by contrast, should largely be stable from v2.10 onwards, and the note points at the Project Status section of the documentation for more detail. That is a real constraint rather than a caveat about future work: a team that has standardised on one of the scientific computing styles is being told to stay on the previous major version for now, while a team starting fresh can use Default or Blue and stay on v2. The alternative to sorting out which style your repository uses is a reformatting diff on the first pull request, which is the fastest way to lose the goodwill of the team you are trying to help. ## Adding the package and formatting a file, a directory or a string Installation is a single package manager call in the Julia REPL. ```julia pkg> add JuliaFormatter ``` The quick start then shows three entry points, and they cover the three things you actually want to do. ```julia julia> using JuliaFormatter # Recursively formats all Julia files in the current directory julia> format(".") # Formats an individual file julia> format_file("foo.jl") # Formats a string (contents of a Julia file) julia> format_text(str) ``` format walks the directory recursively and rewrites the Julia files it finds, format_file handles one file, and format_text takes the contents of a Julia file as a string and returns the formatted result, which is what you want when the code is coming from somewhere other than the filesystem, such as a generated file or a snippet in a test. The README points at the documentation for the full list of options. ## jlfmt for CI, where checking matters more than rewriting Starting from version 2.2.0 the package ships a command line executable, jlfmt, which is installed as a Julia application. ```julia pkg> app add JuliaFormatter ``` The usage examples are the interesting part, because they cover the whole life cycle of a formatter in a repository. ```bash # Format a file and write to stdout jlfmt src/file.jl # Format a file in place jlfmt --inplace src/file.jl # Check if all files in a directory are already formatted with verbose mode jlfmt --check -v src/ # Format all files in a directory with multiple threads jlfmt --threads=6 -- --inplace -v src/ # Show diff without modifying files jlfmt --diff src/file.jl ``` The default is to write to stdout, which makes jlfmt composable in a pipeline, while --inplace rewrites the file. The --check mode is the one that belongs in CI, since it reports whether files are already formatted without touching them, and --diff is what you want in a review comment, since it shows the change without applying it. The --threads flag formats a directory with several workers, and the double dash before the rest of the arguments is the documented way to pass options through. The README also mentions running jlfmt --help for the remaining options, and points at a separate CLI documentation page. ## A repository that formats itself, with pre-commit hooks The top level of the repository is instructive, because it shows how the project expects to be used. There is a .JuliaFormatter.toml file at the root, which is the configuration file for the formatter itself, so the project's own style decisions are recorded in a file that ships with the code rather than in a wiki page. There is also a .pre-commit-config.yaml and a .pre-commit-hooks.yaml, which together mean the project ships a ready-made pre-commit hook definition, so a team can enforce formatting at commit time without writing the hook itself. The rest of the tree is a normal Julia package layout, with src/ for the code, test/ for the test suite, docs/ for the documentation source, bin/ for the command line entry point, and Project.toml for the package metadata. HISTORY_v2.md records the version 2 history, which is worth reading before an upgrade, since v2 is where the style caveat above comes from. The documentation is built with Documenter, and the stable documentation is published at juliaeditorsupport.github.io/JuliaFormatter.jl/stable/. ## The release cadence and what it means for pinning The recent releases are v2.14.0 published on 2026-09-06, v2.13.0 on 2026-08-26 and v2.12.6 on 2026-08-19, and the last push to the repository was on 2026-09-06, the same day as the v2.14.0 tag. That is a fast cadence for a formatter, and it has a direct consequence for how you depend on it. A formatter that changes its output is a formatter that produces diffs, so a project running it in CI on a floating minor version will occasionally fail on files it passed last week, for no change in your own code. The pattern that avoids this is to pin the formatter version in your Project.toml, or to accept the churn and reformat on upgrade. The 2.12 releases also show a patch version being used for fixes, which is the level you would normally take for a formatter that touches every file in the repository. ## Where a formatter is the wrong investment Two situations point elsewhere. The first is a repository where formatting is not actually a source of conflict, which is more common than formatter advocates assume. If a handful of people write the code and the style disagreements are already settled by habit, a formatter adds a dependency, a configuration file, a pre-commit hook and a CI step, and the benefit is close to zero. The second is a team that wants per-file or per-language control. JuliaFormatter operates on Julia code, and a repository that also holds generated files, notebooks with embedded code, or vendored sources needs exclusions for each of those, and the README does not describe a glob or ignore configuration beyond the .JuliaFormatter.toml options. The honest alternative in that case is to run the formatter only on the directories you own, which jlfmt can do by pointing it at a path, and to leave the rest of the tree alone rather than trying to make one tool cover it. ## Conclusion JuliaFormatter.jl fits a Julia team that wants one formatting style enforced across a repository and in CI, and that is willing to commit to the Default or Blue style rather than mix options. It does not fit a project that needs SciMLStyle or YASStyle today, since the README says those styles still have rough edges in v2 and points you at v1 instead, and it does not fit a team that treats formatting as a per-developer preference. Before you adopt it, read the note about which styles are stable, decide whether you want jlfmt in a pre-commit hook, and check the .JuliaFormatter.toml file that already sits at the root of the repository, since that is where the project's own style decisions are recorded. ## FAQ ### How do I install JuliaFormatter.jl? In the Julia package manager, add it with pkg> add JuliaFormatter. To get the command line tool as well, which the README says is available from version 2.2.0, install it as an application with pkg> app add JuliaFormatter. ### Which JuliaFormatter styles are safe to use on version 2? The README says that in v2 the SciMLStyle and YASStyle styles still have a number of rough edges, and that you should consider using v1 of JuliaFormatter if you use those styles. Default and Blue styles should largely be stable from v2.10 onwards, and the Project Status section of the documentation has more detail. ### What is the difference between format, format_file and format_text? format recursively formats all Julia files in the current directory, format_file formats an individual file, and format_text formats a string that holds the contents of a Julia file. The README shows format("."), format_file("foo.jl") and format_text(str) as the three entry points. ### How do I check formatting in CI without changing files? Use the jlfmt executable with the --check flag, for example jlfmt --check -v src/, which reports whether the files in a directory are already formatted. The README also documents --diff to show the changes without applying them, and --inplace to rewrite files, with --threads for a multi-worker directory run. ### Is JuliaFormatter.jl open source? Yes. The package is licensed under the MIT licence, with the licence text in the LICENSE file at the root of the repository, and the default branch is main. The project home is juliaeditorsupport.github.io/JuliaFormatter.jl/. ## Sources - [JuliaEditorSupport/JuliaFormatter.jl on GitHub](https://github.com/JuliaEditorSupport/JuliaFormatter.jl) - [License: MIT](https://github.com/JuliaEditorSupport/JuliaFormatter.jl/blob/main/LICENSE) - [Project website](https://juliaeditorsupport.github.io/JuliaFormatter.jl/) - [README](https://github.com/JuliaEditorSupport/JuliaFormatter.jl/blob/main/README.md) - [Releases](https://github.com/JuliaEditorSupport/JuliaFormatter.jl/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/juliaeditorsupport-juliaformatter-jl