Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Automatically ratchet up coverage thresholds instead of hand-maintaining them

Abierto
  • ¿Algo no está bien?
#1,453 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@YuryShkoda ya está trabajando en esto.

Desde el 3/7/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

refactoring

Problem

jest.config.js hardcodes coverageThreshold.global as fixed numbers:

coverageThreshold: {
  global: {
    statements: 73,
    branches: 60.55,
    functions: 73.54,
    lines: 74
  }
}

These only get updated when someone notices npm run test:mocked failing (threshold not met) and manually edits the numbers — usually while already deep in an unrelated PR. This has two failure modes:

  • Silent stagnation: when coverage improves, nothing bumps the threshold up, so the safety net stays looser than it could be indefinitely.
  • Noisy, unrelated diffs: when coverage regresses, whoever's PR happens to trip the threshold has to manually figure out the right new number and edit CI-adjacent config as a side quest to their actual change.

We want this to self-maintain, the same way semantic-release (already used in this repo's npmpublish.yml) self-maintains the package version — no human edits jest.config.js by hand for this again.

Goal

Coverage thresholds should only ever move in the safe direction (up when real coverage improves) automatically, and a genuine regression should still fail CI clearly - never be silently masked.

Two viable approaches — needs a decision before implementation

Option A: custom script + CI auto-commit (self-hosted, more code to own)
  • A script (e.g. scripts/updateCoverageThresholds.js) runs after npm run test:mocked and reads coverage/coverage-summary.json.
  • For each of the four metrics, if actual coverage > current jest.config.js threshold, rewrite jest.config.js with the new value rounded down slightly (e.g. -0.5pt buffer) rather than an exact match, so a trivial/flaky variance between runs doesn't immediately fail the next build.
  • Never auto-lowers a threshold — only ratchets up. A real regression still fails the existing test:mocked step exactly as it does today, forcing a human decision (fix the coverage, or consciously accept + explain the drop in the PR).
  • Runs as a step in a workflow triggered on push to main (mirroring npmpublish.yml's trigger) — after a PR has already merged, not as part of PR checks — and pushes a bot commit like chore: bump coverage thresholds directly to main, the same way semantic-release pushes its version-bump commit.
  • Needs: write access from the Action to main (existing GITHUB_TOKEN with contents:write, or a PAT if branch protection requires it), and a guard so the bot's own commit doesn't re-trigger itself in a loop.
Option B: external coverage service (Codecov / Coveralls) - likely less code to build and maintain
  • These already solve exactly this class of problem: instead of a static number in the repo, they compare each PR's coverage against the base branch and post a status check like "coverage decreased by X% - failing" or "coverage increased - no threshold to maintain at all."
  • No jest.config.js numbers to bump, no bot-commit workflow to build/maintain, PR-level annotations showing exactly which lines lost coverage, and a badge for the README as a bonus.
  • Trade-off: adds a third-party dependency (an account + a small config file, e.g. codecov.yml), and CI needs to upload the coverage report (coverage/lcov.info) to the service each run.
  • This repo already uses artiomtr/jest-coverage-report-action in run-tests.yml for PR coverage comments - worth checking whether it (or a config tweak to it) already covers this need before adding another service.

Suggested next step

  • Decide between Option A and Option B (see trade-offs above) - or confirm neither and reconsider artiomtr/jest-coverage-report-action's existing capabilities first, since it's already wired into run-tests.yml.
  • If Option A: write scripts/updateCoverageThresholds.js, wire it into a new (or existing, post-merge) workflow step, decide the exact buffer value, and add the loop-prevention guard for the bot's own commits.
  • If Option B: pick a service, add the upload step to run-tests.yml, configure its ratcheting/regression rules, and remove the now-redundant coverageThreshold block from jest.config.js.
  • Either way: document the chosen mechanism (e.g. in CONTRIBUTING.md or a code comment near coverageThreshold) so contributors know they should never hand-edit the threshold numbers going forward.

Non-negotiable

Whichever option is picked, a genuine coverage regression must still fail CI loudly - this issue is about removing manual upkeep of the good direction (raising the bar), not about loosening enforcement.

Lenguaje dominante
TypeScript
Estrellas
40
Forks
6
Merge medio
9 h 40 min
PR fusionados (30 d)
18

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 sasjs/cli

Todos los issues de sasjs/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.