I've been deep in the weeds on formatting performance lately. My team's codebase is growing fast, and our current Prettier setup is starting to feel sluggish on commit hooks.
I know dprint is built in Rust and boasts incredible speed. But I'm curious about real-world experience, especially with large monorepos.
Has anyone switched from Prettier to dprint at scale? Was the speed-up noticeable enough to justify the config migration? I'm particularly interested in TypeScript/React projects.
I'm a frontend lead at a mid-sized e-commerce company, and we maintain a large Next.js monorepo with around 1.5 million lines of TypeScript/React. We've run both Prettier and dprint in our CI pipelines and on developer machines.
Here is a breakdown based on our migration last year:
**Raw Formatting Speed**: dprint is consistently 5-10x faster for us on a fresh run with no cache. Our Prettier run took about 90 seconds for the whole monorepo; dprint completes in 9-15 seconds. This was the main justification for the switch.
**Configuration Migration**: The migration effort was moderate, taking about two days of focused work. dprint's JSON config is similar, but you must rebuild any complex overrides. The main hurdle was replicating our specific `.prettierignore` patterns using dprint's `excludes` and `includes` globs, which work a bit differently.
**Plugin Ecosystem & Stability**: This is where Prettier still wins. While dprint's core TypeScript/JavaScript formatting is excellent and stable, some niche community plugins for other languages in our repo (like CSS-in-JS libraries) weren't as mature. We had to temporarily keep Prettier for a few edge cases until plugins caught up.
**Integration and Cache Warm-up**: The speed gain is most dramatic on CI from a cold start. However, for local commit hooks, the difference feels less significant if you already have Prettier's cache working well. The true pain point it solved was our 10-minute CI formatting job, which now finishes in under a minute.
I'd recommend dprint specifically if your primary bottleneck is CI runtime or full-repo formatting, and your stack is mainstream (TS/JS, JSON, Markdown). If you heavily rely on a wide variety of well-established Prettier plugins for other languages or have highly customized formatting rules, the switch might be rougher.
To make the call clean, tell us: what's your actual CI job duration for formatting, and do you have any non-JS/TS languages in the mix that require formatting?
Stay grounded, stay skeptical.
That's a really useful breakdown, thanks. The plugin maturity point is key - we hit the same snag with our GraphQL codegen files. Dprint's plugin for it was still a bit rough, so we kept a prettier script just for that directory as a stopgap.
The config migration taking two days lines up with our experience. I'd add that if your team has custom IDE plugins or editor integrations tied to prettier, that's another layer of change management to plan for. You don't want folks losing format-on-save the day you switch.
ian