Track TypeScript errors in CI

Aperta
#8,786 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #8787 di @talissoncosta — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, typescript
Ambito
ci-cd

Direzione di ricerca

Start by reading the existing CI workflows to see how lint and unit tests run, and reuse the sticky PR comment already built for Visual Regression. Run tsc --noEmit locally to reproduce the per-file error counts, starting with common/stores/feature-list-store.ts (147 errors). Done when a PR shows the 890 to N comparison against main's merge base and the workflow never blocks a merge.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

front-end tech-debt

CI runs lint and unit tests but not tsc. Main has about 890 type errors across 351 files, and nothing tells us when a PR adds more.

Add a report on every PR that compares its type errors with main's, without blocking the merge.

  • On push to main: run tsc --noEmit, upload per-file error counts as an artifact
  • On PRs: run tsc once, compare with main's counts for the merge base (fall back to the latest main)
  • Sticky PR comment, like the Visual Regression one:
    • 🟢 "Type errors: 890 → 884 (−6)" when the PR fixes some
    • 🔴 "Type errors: 890 → 892 (+2)", listing the files that gained errors
    • nothing to report when unchanged
  • Not a required check, so it never blocks a merge

Later, once it has proved quiet: consider making it required.

The biggest single file is common/stores/feature-list-store.ts (147 errors), which shrinks with the Flux migration.

Lingua principale
Python
Stelle
7.1k
Fork
603
Merge medio
3g 8h
PR unite (30g)
102

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Flagsmith/flagsmith

Tutte le issue di Flagsmith/flagsmith

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.