Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

util/config: assertRequiredString reports 'must be a string' when the property is missing, hiding 'required field omitted' errors

Aperta Adatta ai principianti
  • Qualcosa non va?
#67 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
cli, tooling

Direzione di ricerca

Inizia in src/prompt-generators/util/config.ts, in assertRequiredString, quindi esamina i chiamanti in bugzilla/config.ts, gitlab/config.ts, per-file.ts e json.ts. Esegui i casi rilevanti in src/util/test/load-cli-config.test.ts, in particolare alle righe 696 e 1283; il lavoro è completato quando le chiavi mancanti segnalano che il campo è obbligatorio, mentre i tipi errati mantengono il messaggio esistente.

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

Descrizione

bug S3

Observed behavior

assertRequiredString in src/prompt-generators/util/config.ts (lines 63-71) uses a single error message for two distinct failure modes:

export function assertRequiredString(
  value: Record<string, unknown>,
  key: string,
  field: string,
): void {
  if (!(key in value) || typeof value[key] !== 'string') {
    throw new Error(`${field} must be a string`);
  }
}

If the property is entirely missing from value, the user sees:

gitlab.search.project must be a string

That is the same message they would see if they had assigned a number, null, or an array to the field. A user who forgot to add project to their config (the most common configuration mistake for a required field) gets a message that suggests they assigned the wrong type, not that they omitted the field. The existing test in src/util/__test__/load-cli-config.test.ts at line 696 actually asserts this exact misleading message for a config where project is omitted entirely.

Expected behavior

The two failure modes should produce different messages, e.g.:

  • Missing key: gitlab.search.project is required
  • Wrong type: gitlab.search.project must be a string

This matches what other validators in the codebase already do for date fields (see assertRequiredDateField in bugzilla/config.ts, which also conflates the two cases but is less commonly hit). The downstream callers in bugzilla/config.ts, gitlab/config.ts, per-file.ts, and json.ts all funnel required-string validation through this helper, so fixing it once propagates.

Minimal reproduction

import { assertRequiredString } from './prompt-generators/util/config.js';

// Property entirely missing - error is misleading
assertRequiredString({}, 'foo', 'test.foo');
// Throws: \"test.foo must be a string\"  (should be \"test.foo is required\")

// Property has wrong type - error is accurate
assertRequiredString({ foo: 5 }, 'foo', 'test.foo');
// Throws: \"test.foo must be a string\"

Suggested fix

Split the check into two branches with distinct messages:

export function assertRequiredString(
  value: Record<string, unknown>,
  key: string,
  field: string,
): void {
  if (!(key in value)) {
    throw new Error(`${field} is required`);
  }
  if (typeof value[key] !== 'string') {
    throw new Error(`${field} must be a string`);
  }
}

Existing tests that match against the old message (e.g. load-cli-config.test.ts:696, :1283) would need to be updated to match the new "is required" message for missing-key cases.

Severity

S3 - confusing API. The behaviour is correct (the error is thrown), but the message misleads users about what they did wrong.

Lingua principale
TypeScript
Stelle
2
Fork
1
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 joewalker/loop-the-loop

Tutte le issue di joewalker/loop-the-loop

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.