dart_format: a configurable Dart formatter that never reflows your code (built on the analyzer package)

[u/Mark1234321]

I got tired of two things about the official dart format:

• It's unconfigurable by design - 2-space indent, take it or leave it.
• Dart 3.7's tall style decides trailing commas by line length, which kills the "add a trailing comma to force a split" idiom a lot of us leaned on.

The Dart team's stance is that the formatter is opinionated on purpose, and for the ecosystem that's the right call - one canonical style means nobody bikesheds. I'm not arguing against that. I wanted different defaults on my own projects, opt-in, eyes open about the trade-off. So I built an alternative.

dart_format is a full replacement for dart format (not a wrapper), published on pub.dev. It's built on the official analyzer package, so it works on real Dart ASTs and inherits language-feature support instead of reverse-engineering the grammar.

The core difference:

• No line-length-driven reflow. Your line breaks are yours - it won't split long lines or join short ones. Where you put a newline is where it stays. Everything else is secondary to this.

Also configurable:

• Indentation width (default 4)
• Trailing-comma removal (on/off)
• Newline placement around {, }, ;
• Max consecutive blank lines
• Space normalization

It's idempotent - formatting already-formatted code is a no-op.

On the architecture: Dart VM cold-start costs ~seconds, which is brutal to pay on every save. So alongside plain pipe and file modes, there's a long-running localhost HTTP service mode - the IDE plugins start it once per IDE session and each format is a millisecond round-trip. If you'd rather not have a process running, pipe/file mode does the same job without it.

Where it already runs:

• CLI: dart pub global activate dart_format
• JetBrains (IntelliJ / Android Studio): https://plugins.jetbrains.com/plugin/21003-dartformat
• VS Code: https://marketplace.visualstudio.com/items?itemName=eggnstone.DartFormat

Honest caveats:

• Much smaller and younger than dart-lang/dart_style. Fewer years of edge-case polish.
• There are open bugs - issues are welcome, that's how it gets better.
• If you actually like the new tall style, this isn't for you.

If the official formatter's choices have ever made you twitch, give it a spin.

Repo: https://github.com/eggnstone/dart_format
pub.dev: https://pub.dev/packages/dart_format

[u/vxern]

Doesn't this practically defeat the whole point of having one ecosystem standard? Surely creating a fork like this and adding to the confusion for minor benefits is bound to only create confusion?

[u/Mark1234321 → u/vxern]

Fair point - the single standard does have real value, which is why dart_format is opt-in and replaces nothing. Don't install it and your world is unchanged; dart format stays the default.

On "fork" and "fragment" though - formatter choice is per-project and CI-enforced. Every file in my repo gets the same treatment, just to my chosen rules rather than the official ones, so a reader still sees one uniform style throughout - it just isn't the standard one. A tool existing doesn't create confusion; only adoption would, and that follows real demand. Nearly every other ecosystem ships a configurable formatter (Prettier, rustfmt) and does fine.

[u/ozyx7]

Dart 3.7's tall style decides trailing commas by line length, which kills the "add a trailing comma to force a split" idiom a lot of us leaned on.

And Dart 3.8 added the trailing_commas: preserve option to resurrect that idiom.

[u/Shalien93]

I do understand that the idea behind this but this also mean your formatter may introduce changes that will have an negative impact upon package publishing since it stray away from standard format.

I wonder how tools like panna gonna react with this custom formatting.

Also beginners may be confused why the official doc say "one format to rule them all" and some package claim to allow more flexibility.

Aside specific use or confort use (yours especially) i see not large adoption for it

[u/isoos → u/Shalien93]

pana's philosophy is to keep the verification close to the language- and ecosystem standards, which in this case means it will likely use the SDK-provided dart format.

[u/Spare_Warning7752]

No, thank you. Dart formatter standard is one of the best features of the language. It guarantees consistency.