Track TypeScript errors in CI

Abierto
#8,786 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #8787 de @talissoncosta — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, typescript
Área
ci-cd

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
7.1k
Forks
603
Merge medio
3 d 8 h
PR fusionados (30 d)
102

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Flagsmith/flagsmith

Todos los issues de Flagsmith/flagsmith

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.