to-json-schema: errorMode 'ignore'/'warn' emits invalid JSON Schema for string minValue/maxValue/gtValue/ltValue

[maximilliangrand]

Bug

With errorMode: 'ignore' or 'warn', converting a string (or any non-number) schema that carries minValue/maxValue/gtValue/ltValue produces an invalid JSON Schema: the string requirement is written into minimum/maximum/exclusiveMinimum/exclusiveMaximum, which must be numbers.

Repro (published @valibot/to-json-schema 1.7.1, valibot 1.4.2)

import * as v from 'valibot';
import { toJsonSchema } from '@valibot/to-json-schema';

toJsonSchema(v.pipe(v.string(), v.minValue('m')), { errorMode: 'ignore' });
// => { type: 'string', minimum: 'm', $schema: '.../draft-07/schema#' }

v.pipe(v.string(), v.minValue('m')) is a valid Valibot schema (lexicographic string comparison). Ajv rejects the emitted schema: schema is invalid: data/minimum must be number. The same happens with maxValue (maximum), gtValue (exclusiveMinimum) and ltValue (exclusiveMaximum), in both 'ignore' and 'warn' modes.

Expected vs actual

The README says non-throw modes ignore unsupported actions (e.g. v.pipe(v.string(), v.creditCard()) with errorMode: 'ignore' → { type: 'string' }, which I confirmed). So the expected output here is { type: 'string' }. The actual output injects a non-numeric minimum, which violates the JSON Schema meta-schema.

Cause

In packages/to-json-schema/src/converters/convertAction/convertAction.ts, the min_value/max_value/gt_value/lt_value cases record the "not supported on type" error but then still assign the numeric keyword unconditionally (e.g. jsonSchema.minimum = valibotAction.requirement as number). That assignment should be skipped when the type isn't number/integer, like the existing OpenAPI and includes branches already do.

[dosubot]

Hi @maximilliangrand! I'm Dosu and I'm helping the Open Circle team.

Your analysis is spot-on. Looking at the source, all four cases have the same structural bug — the type guard records an error but does not break or use an else, so the numeric keyword assignment runs unconditionally:

• min_value (lines 474–483): checks type, adds error, then always executes jsonSchema.minimum = valibotAction.requirement as number [1]
• max_value (lines 423–432): same pattern — jsonSchema.maximum is always written [2]
• gt_value (lines 295–311): has a break for the OpenAPI-3.0 guard but not for the type guard, so jsonSchema.exclusiveMinimum is still written for non-number types [3]
• lt_value (lines 385–401): same as gt_value — jsonSchema.exclusiveMaximum is always written [4]

The fix is to add a break (or restructure with else) in the type-mismatch branch of each case. For example, min_value should become:

case 'min_value': {
  if (jsonSchema.type !== 'number' && jsonSchema.type !== 'integer') {
    errors = addError(
      errors,
      `The "min_value" action is not supported on type "${jsonSchema.type}".`
    );
    break; // ← add this
  }
  jsonSchema.minimum = valibotAction.requirement as number;
  break;
}

The same pattern applies to max_value, gt_value, and lt_value. Note that related cases like empty, length, max_length, min_length, and non_empty already have a similar bug where they still write maxLength/minLength even when the type isn't string or array — they add the error but fall through to the assignment as well [5] [6] [7] [8]. However, since those at least write a valid JSON Schema keyword (minLength/maxLength accept numbers), the output doesn't violate the meta-schema the way minimum: 'm' does — it's just semantically incorrect rather than structurally invalid.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.