War Story: How a Prettier 3.3 Formatting Change Broke 100+ PRs for 2 Hours During Sprint Planning

It was 9:00 AM on a Tuesday, the start of our biweekly sprint planning session. The engineering team was gathered in the conference room, laptops open, ready to size upcoming tickets. Then the Slack notifications started flooding in.

The First Sign of Trouble

Our CI pipeline, which runs Prettier on every PR push, began failing en masse. Within 15 minutes, over 100 open pull requests were marked red, all citing "Formatting errors detected by Prettier 3.3". Our team had upgraded Prettier to 3.3 the night before as part of a routine dependency update, following our standard process of applying minor version bumps during low-traffic windows.

We initially thought it was a configuration drift issue. Our Prettier config was pinned to v3, but we hadn't restricted the minor version. The 3.3 release included a subtle change to how it formatted multi-line object literals with trailing commas in TypeScript files—a rule we'd explicitly enabled in our config, but the new behavior deviated from the 3.2 output in a way that invalidated every existing PR that touched TypeScript object definitions.

The Sprint Planning Chaos

With sprint planning underway, product managers were waiting for us to finalize point estimates for the next cycle. Instead, engineers were frantically trying to rebase their PRs, only to have Prettier 3.3 reformat their changes, creating merge conflicts with the already-broken main branch. Our CI queue backed up to 40 minutes, and new PRs couldn't be merged at all.

We tried a quick fix: downgrading Prettier back to 3.2 in our root package.json and pushing the change to main. But because the 3.3 formatting had already been applied to many PRs, rebasing those PRs onto the downgraded main still triggered CI failures, as the PRs' code had been formatted with 3.3, which conflicted with the now-enforced 3.2 rules.

The Resolution

Our lead engineer made a call: we'd temporarily disable Prettier checks in CI for 2 hours, allow all pending PRs to merge with their existing formatting, then re-run a one-time batch format of the entire codebase using Prettier 3.3, push that as a single large PR, and re-enable CI checks once the batch format was merged.

It took 90 minutes to merge all 100+ pending PRs, as we had to manually approve each one (since CI was disabled, we relied on manual code review). Once the batch format PR was merged, we re-enabled Prettier 3.3 checks, and CI stabilized. By 11:00 AM, exactly 2 hours after the first failure, our pipeline was green again, and we were able to finish sprint planning 30 minutes late.

Lessons Learned

• Pin dependency versions to exact minors or use a lockfile to prevent unexpected minor version upgrades in CI.
• Test formatting tool upgrades on a staging branch with a small subset of PRs before rolling out to main.
• Have a rollback plan for CI-breaking changes, including temporary check disabling and batch reformatting procedures.
• Avoid running dependency upgrades right before critical team events like sprint planning.

We haven't had a repeat incident since, but that 2-hour window remains a cautionary tale for our team about the risks of unpinned formatting tool upgrades.