Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Decide whether to adopt a code formatter (Prettier or oxfmt)

Offen
  • Stimmt etwas nicht?
#112 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
tooling

Rechercherichtung

Start by reviewing the formatter measurements and the context in #46 and #109, then consider the rebase impact on #50 and #51. This issue is done when maintainers decide whether to adopt a formatter or defer; if they choose adoption, the issue lists .git-blame-ignore-revs and the lint-and-types job as places to update.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

question

The question

Should this repo adopt an automatic code formatter? Opening this with the measurements already taken, so whoever decides has the numbers to hand rather than having to gather them again.

My read, offered as input rather than a conclusion: the code already looks consistent, and adopting Prettier today would reformat roughly two-thirds of the codebase. That seems like a lot of churn for something nothing is currently flagging, so I'd lean toward holding — but the figures are below and the call is very much the maintainers'.

What was measured

Prettier 3.9.6, configured to match the style the repo already uses (semi: false, singleQuote: true), run over all 518 tracked .ts/.tsx files:

printWidth Files reformatted
80 (default) 465 / 518
100 377 / 518
120 340 / 518
140 333 / 518

At printWidth: 120 that is 340 files, 7,928 insertions, 4,084 deletions — roughly 12,000 lines of pure churn. There's no setting that makes it small; the floor is about 64% of the codebase.

The reformatted tree does still pass tsc --noEmit, so this is safe, just enormous.

Two concerns I checked that turned out not to apply

Noting these in case they'd otherwise be assumed to be blockers:

  • Whether it reintroduces the dependency problem that drove the ESLint → oxlint swap. It doesn't appear to — Prettier 3.9.6 has zero runtime dependencies, so it shouldn't be able to pull in the minimatch@3 → brace-expansion chain that motivated that swap.
  • Whether it would fight the linter. It doesn't look like it — none of the 132 current oxlint warnings are formatting-related.

What gives me pause

  1. No problem is being reported. The code is hand-formatted but genuinely consistent. Nothing in lint output, review, or CI is complaining about style.
  2. git blame cost is unusually high here. This codebase leans hard on explanatory comments and commit archaeology — a lot of the "why" lives in blame and in git show at a specific ref, not just in the current file. Scrambling blame across 64% of files taxes the thing this repo is unusually good at.
  3. It conflicts with everything in flight — #50, #51, and any open branch would need rebasing through a 12,000-line reformat.

If we do it anyway

The low-regret path:

  1. Land it as one isolated commit that changes nothing else.
  2. Add that commit SHA to .git-blame-ignore-revs so git blame skips it.
  3. Merge when no PRs are open.
  4. Add prettier --check to the lint-and-types job so it can't drift afterward.

The other option

oxfmt — oxc's own formatter, same toolchain already chosen for linting — would be the natural fit and avoids running two independent tools with their own opinions. It's at 0.66.0 as of 2026-09-06, so pre-1.0. Probably worth revisiting once it stabilises rather than adopting Prettier now and migrating later.

Context

Came up while working #46 / #109.

Vorherrschende Sprache
TypeScript
Sterne
16
Forks
2
Ø Merge
7 Std. 4 Min.
Gemergte PRs (30 T.)
157

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus answerLoops/answerLoops

Alle Issues in answerLoops/answerLoops

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.