Proposal: Add Action Execution APIs to Valibot

[jsudelko]

Would you consider adding APIs for executing actions that can throw errors, following Valibot's existing mental model and function signatures?

Packages like neverthrow or better-result require different ways of thinking about composition (e.g Switching between v.pipe(v.string(), v.email()) and Result.try() or fromThrowable()) and converting between Valibot's issues/output types and Result<T, E> types adds boilerplate.

Example (Bikeshedable)

// Basic action wrapper
const fetchData = v.pipe(
  v.tryAsync(() => fetch('https://api.example.com/data'), { retries: 3, timeout: 5000 }),
  v.object({ data: v.string() }),
);

// With typed error handling
const result = v.executeAsync(fetchData);

Alternative Approaches

I understand this is a departure from Valibot's current scope as a pure validation library. The reason why this is difficult to implement as an external package is it may require slight changes to Valibot core such as v.pipe(...) and BaseIssue.

[fabian-hiller]

Hey 👋 thanks for reaching out! Wouldn't it be better to fetch the data first and then validate it with Valibot? This would give you full control over the data fetching process. @dosu what do you think?

[dosubot[bot]]

Yes, fetching the data first and then validating it with Valibot is generally the better approach and aligns with Valibot’s design philosophy. Valibot is built as a modular, type-safe schema validation library focused on validating and transforming data after it’s been received, not on executing side-effectful actions like data fetching within its pipeline. This separation gives you full control over how you fetch data, handle retries, timeouts, and errors, and then lets you validate the resulting data with Valibot’s rich schema and error reporting system (docs, thesis).

Integrating action execution (like fetching) directly into Valibot’s pipeline would require significant changes to the core, especially around error handling and pipeline execution. Valibot’s validation results and error types (like BaseIssue and OutputDataset) are much richer and more structured than typical Result<T, E> types, making conversion non-trivial and potentially losing valuable error context (code, pipeline discussion).

If you want ergonomic composition, you can always fetch data (with your preferred error-handling strategy), then pass the result to Valibot for validation. This keeps concerns cleanly separated and leverages the strengths of both your data-fetching tools and Valibot’s validation capabilities.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jsudelko]

I admit I didn't use the best example. Kindly ignore the example, and pay attention and respond to everything else. The key thing is uniformity mental model and input/output signature.

[fabian-hiller]

Do you have example code on how you would like to use it. Feel free to provide pseudo code. Just so that I get an idea.

[jsudelko]

I have a strong intuition that there's something good here, but I haven't yet had the time to do a deep dive on Valibot and better-result internals and collect use cases to motivate design.

I accepted status quo for my purposes but might revisit later as time allows. Feel free to disregard if you have other priorities.