Standard schema contract violation

[Xelson]

valibot 1.1.0

const schema = v.object({
  first: v.string(),
  second: v.pipe(v.string(), v.nonEmpty()),
});

console.log(schema["~standard"].validate({ first: "", second: "" }))

This code gives such output:

{
    "value": {
        "first": "",
        "second": ""
    },
    "typed": true,
    "issues": [
        {
            "kind": "validation",
            "type": "non_empty",
            "input": "",
            "expected": "!0",
            "received": "0",
            "message": "Invalid length: Expected !0 but received 0",
            "path": [
                {
                    "type": "object",
                    "origin": "value",
                    "input": {
                        "first": "",
                        "second": ""
                    },
                    "key": "second",
                    "value": ""
                }
            ]
        }
    ]
}

But actually such output is violating standard schema contract because value and issues cannot exists at a time

    export type Result<Output> = SuccessResult<Output> | FailureResult;
    /** The result interface if validation succeeds. */
    export interface SuccessResult<Output> {
        /** The typed output value. */
        readonly value: Output;
        /** The non-existent issues. */
        readonly issues?: undefined; // <--- we should have `issues: undefined` when `value` is defined
    }
    /** The result interface if validation fails. */
    export interface FailureResult {
        /** The issues of failed validation. */
        readonly issues: ReadonlyArray<Issue>;
    }

Such mismatch can lead (and has already led to in my case) to errors in the code that checks for errors based on the absence of value as a result of validation.

[dosubot]

Hi @Xelson! I'm Dosu and I’m helping the valibot team.

You're correct—Valibot v1.1.0 does not strictly enforce the contract that value and issues are mutually exclusive in the validation result. At runtime, it's possible to get both properties in the result, even though the TypeScript types suggest otherwise. This is a known design trade-off: the maintainers have discussed the pros and cons of enforcing a stricter protocol, but currently Valibot relies on consumers to check for the presence of issues rather than guaranteeing exclusivity in the result object [discussion].

This behavior can cause problems if your code assumes that the absence of value always means validation failed. As a workaround, always check for the presence of issues to determine failure, rather than relying solely on the presence or absence of value.

There are ongoing discussions about standardizing this protocol, but as of v1.1.0, this contract violation is expected and not yet fixed [discussion]. If you need stricter guarantees, you may need to add a utility function to normalize the result or wrap the validation to enforce the contract in your own code.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[fabian-hiller]

Hey! Thank you for reporting this issue. How do you test for .value? With 'value' in result? We recommend using .issues as the discriminator but you are right that our current implementation is not perfect. We could and probably should improve it but it would increase the bundle slightly.

[Xelson]

How do you test for .value? With 'value' in result?

Yeah correct, I don't know why I did it that way but typescript was ok about that. And now i'm just checking presence of .issues and this one is more readable too

[EskiMojo14]

necroposting, but it's worth remembering that typescript types/interfaces are a minimum contract - the lack of a key in your type does not guarantee it won't exist.

interface User {
  firstName: string;
  lastName: string;
}

function greet({ firstName, lastName }: User) {
  console.log(`Hello ${firstName} ${lastName}!`)
}

const user = { firstName: "John", lastName: "Smith", age: 20 }

greet(user) // no type error

TS does error in cases where knowledge of the extra key is immediately lost, in an effort to catch typos:

const user: User = { firstName: "John", lastName: "Smith", age: 20 } // extra key errors

greet({ firstName: "John", lastName: "Smith", age: 20 }) // extra key errors

Following this logic, Valibot's result does indeed match the FailureResult interface.

related:
https://thoughtspile.github.io/2023/01/23/typescript-sets/
https://www.totaltypescript.com/books/total-typescript-essentials/the-weird-parts#excess-property-warnings

[Xelson]

the lack of a key in your type does not guarantee it won't exist.

Fair point, but my case is not about a missing key — It's about an interface violation:

export interface SuccessResult<Output> {
    /** The typed output value. */
    readonly value: Output;
    /** The non-existent issues. */
    readonly issues?: undefined; // <--- we should have `issues: undefined` when `value` is defined
}

According to this interface, if the return value has a value key, then the issues key should either not exist or be undefined. However, in the Valibot validation result, we're getting both value and issues (with an array value) at the same time.

[EskiMojo14]

that's because you're not getting a SuccessResult, you're getting a FailureResult.