Valibot resolver doesn't collect rawCheck issues when base schema fails

[stefan-girlich]

Hi everyone,

I ran into an issue where validation errors from v.rawCheck weren't showing up in my form
until all other fields were valid first. Once they became valid once, errors would show
correctly even after making those fields invalid again.

Environment

• react-hook-form 7.56.3
• @hookform/resolvers 5.2.2

Root issue

When using v.rawCheck for custom validation logic, issues I add via addIssue() don't appear
in the form errors if the base schema validation fails (dataset.typed === false).

The resolver uses safeParseAsync which doesn't seem to include rawCheck issues when the
schema isn't fully "typed":

const result = await safeParseAsync(schema, values, schemaOpts);

if (result.issues) {  // ⚠️ rawCheck issues missing when dataset.typed is false
// process errors...
}

Workaround

Switching to a custom resolver with parse/parseAsync (which throws a ValiError) that collects all issues from the
pipeline, including rawCheck issues regardless of dataset.typed:

try {
const parsed = await parseAsync(schema, values, schemaOpts);
return { values: parsed, errors: {} };
} catch (error) {
if (isValiError(error)) {
  // error.issues contains ALL issues, including rawCheck ✅
  return { values: {}, errors: toNestErrors(parseErrors(error.issues, ...), options) };
}
throw error;
}

I lack the experience with react-hook-form resolvers and valibot to tell what the expected behavior should be.
Happy to submit a PR if this should be fixed in the resolver.

Full valibotResolver.ts code with workaround

import { toNestErrors } from '@hookform/resolvers'
import { appendErrors, FieldError, FieldErrors, FieldValues, Resolver } from 'react-hook-form'
import * as v from 'valibot'

type ResolverOptions = {
  mode?: 'sync' | 'async'
  raw?: boolean
}

const parseErrors = (
  issues: v.BaseIssue<unknown>[],
  validateAllFieldCriteria: boolean
): FieldErrors => {
  const errors: Record<string, FieldError> = {}

  for (const issue of issues) {
    if (!issue.path) {
      continue // eslint-disable-line no-continue
    }
    const _path = issue.path.map(({ key }) => key).join('.')

    if (!errors[_path]) {
      errors[_path] = { message: issue.message, type: issue.type }
    }

    if (validateAllFieldCriteria) {
      const { types } = errors[_path]
      const messages = types && types[issue.type]

      errors[_path] = appendErrors(
        _path,
        validateAllFieldCriteria,
        errors,
        issue.type,
        messages ? ([] as string[]).concat(messages as string[], issue.message) : issue.message
      ) as FieldError
    }
  }

  return errors
}

/**
 * Custom valibot resolver for react-hook-form.
 *
 * Uses `parse`/`parseAsync` instead of `safeParse`/`safeParseAsync` (used by @hookform/resolvers) to ensures that 
 * issues from `rawCheck` are collected even when the base schema fails validation.
 * The official resolver's `safeParse` approach doesn't include `rawCheck` issues when `dataset.typed` is false.
 */
export const valibotResolver =
  <TSchema extends v.GenericSchema<FieldValues>>(
    schema: TSchema,
    schemaOptions?: v.Config<v.InferIssue<TSchema>>,
    resolverOptions: ResolverOptions = {}
  ): Resolver<v.InferInput<TSchema>> =>
  async (values, _, options) => {
    try {
      const schemaOpts = {
        abortEarly: false,
        abortPipeEarly: false,
        ...schemaOptions,
      }

      const parsed =
        resolverOptions.mode === 'sync'
          ? v.parse(schema, values, schemaOpts)
          : await v.parseAsync(schema, values, schemaOpts)

      return {
        values: resolverOptions.raw ? values : parsed,
        errors: {} as FieldErrors,
      }
    } catch (error) {
      if (v.isValiError(error)) {
        return {
          values: {},
          errors: toNestErrors(
            parseErrors(
              error.issues,
              !options.shouldUseNativeValidation && options.criteriaMode === 'all'
            ),
            options
          ),
        }
      }

      throw error
    }
  }

[chrisjcthomas]

This happens due to how Valibot's pipeline mechanics interact with safeParse when a dataset is untyped.

Why this happens

In Valibot, v.pipe() chains validation actions. If an initial type check fails (for example, a string schema receives an invalid type or fails base parsing), Valibot marks dataset.typed = false on the pipeline dataset.

By design in Valibot's pipeline architecture, subsequent pipeline actions like v.rawCheck or v.check do not execute on untyped datasets to prevent runtime errors (since the input shape cannot be guaranteed for downstream checks). When safeParseAsync is used, it only returns issues accumulated up to the point of pipeline failure.

When you switched to parseAsync throwing a ValiError, the execution semantics were catching whatever issues were thrown, but the underlying pipeline execution behavior remains tied to dataset typing.

Structuring custom checks in Valibot

If you want cross-field or custom validation logic to run alongside base field validations rather than being blocked by an individual field's pipeline failure, the recommended patterns are:

1. Object-level rawCheck / forward:
   Place the v.rawCheck on the parent v.object({...}) rather than inside a specific field's pipeline. Combine this with v.forward to attach the error to the specific field path:

   import * as v from 'valibot';
   
   const schema = v.pipe(
     v.object({
       email: v.pipe(v.string(), v.email()),
       confirmEmail: v.string(),
     }),
     v.rawCheck(({ dataset, addIssue }) => {
       if (dataset.value.email !== dataset.value.confirmEmail) {
         addIssue({
           message: 'Emails do not match',
           path: [{ key: 'confirmEmail', value: dataset.value.confirmEmail, origin: 'value' }],
         });
       }
     })
   );

2. Schema options with abortPipeEarly: false:
   Ensure abortPipeEarly: false is passed in the resolver options so Valibot attempts to run subsequent independent pipeline items where possible.

Your custom resolver workaround works because it handles full error formatting on caught ValiErrors, but structuring composite checks at the object level via v.forward / object-level v.rawCheck avoids the pipeline blockage natively.

[Mike-Animal-Counseling]

I'd separate the parser choice from which parts of the schema are ready to be checked. With the same schema, input and options, changing safeParseAsync to parseAsync did not add any issues in my test: the latter threw the same issue list that the former returned.

Also, rawCheck can receive dataset.typed === false; its callback ran in that state in both tests. A guard such as if (dataset.typed) inside the callback can then skip your custom check. Moving it to the object level alone doesn't make the entire object typed.

For a check that only needs a few fields, Valibot's partialCheck is useful:

const schema = v.pipe(
  v.object({
    email: v.string(),
    confirmEmail: v.string(),
    age: v.number(),
  }),
  v.forward(
    v.partialCheck(
      [['email'], ['confirmEmail']],
      input => input.email === input.confirmEmail,
      'Emails do not match',
    ),
    ['confirmEmail'],
  ),
);

With different email strings and age: 'wrong type', this produced both the age error and the mismatch on confirmEmail. The standard valibotResolver(schema) preserved both. If one of the selected email fields itself has an invalid type, the partial check is skipped, as intended.

I checked this with Valibot 1.5.0, including an isolated install of your RHF 7.56.3 / resolvers 5.2.2 combination. Resolvers 6.0.2 behaved the same. Your Valibot version and actual schema would still be needed to explain why switching parsers changed the result in your application.

The rawCheck example shows the typed guard; partialCheck documents why it can work before unrelated fields are valid.

AI-assisted; the parser comparison and resolver checks above were run locally.