Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#112 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
typescript
Domaine
tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
16
Forks
2
Merge moyen
8 h 56 min
PR mergées (30 j)
126

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de answerLoops/answerLoops

Toutes les issues de answerLoops/answerLoops

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.