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

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#67 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
84/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
cli, tooling

Línea de trabajo

Comienza en src/prompt-generators/util/config.ts, en assertRequiredString, y luego inspecciona los llamadores en bugzilla/config.ts, gitlab/config.ts, per-file.ts y json.ts. Ejecuta los casos relevantes en src/util/test/load-cli-config.test.ts, especialmente las líneas 696 y 1283; se considera terminado cuando las claves ausentes indiquen que el campo es obligatorio, mientras que los tipos incorrectos conserven el mensaje existente.

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

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
1
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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

Todos los issues de joewalker/loop-the-loop

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.