Should InferInput return a type that is deep readonly?

[jhnns]

I've encountered a problem and wanted to get your opinion on it. I have the following simplified example:

const Schema = v.pipe(v.tuple([]), v.readonly());

const createTuple = () => [] as const;

type Input = v.InferInput<typeof Schema>;

const input: Input = createTuple();
//           ^ The type 'readonly []' is 'readonly' and cannot be assigned to the mutable type '[]'

I've set up a Stackblitz here so you can play around with it: https://stackblitz.com/edit/stackblitz-starters-qhcxx34a?file=index.ts (you may need to log in to see the type error)

One possible solution would be for InferInput to always return a type wrapped in ReadonlyDeep. In my opinion, this is correct, as parse does not mutate the input as far as I understand.

Is this correct, or are there side effects that I haven't considered yet?

[dosubot]

InferInput in Valibot currently infers mutable types by default and does not wrap them in deep readonly types, even if the schema uses v.readonly. This is intentional: readonly transformations in Valibot are designed to affect only the output type, not the input type. Making InferInput always return a deep readonly type (like wrapping with ReadonlyDeep) could break existing code and reduce flexibility, since many users expect to provide mutable data as input and only want readonly guarantees on output.

Valibot's parse function does not mutate its input, so from a safety perspective, you can safely cast outputs as deeply readonly if you want immutability guarantees in your codebase. If you need deep readonly types, the recommended approach is to cast the output using a utility like DeepReadonly from ts-essentials or type-fest, rather than changing InferInput globally. Readonly-ness in Valibot schemas does not cascade automatically; you need to apply it at each level for fine-grained control. For most use cases, keeping input types mutable and output types readonly provides the best balance of safety and flexibility [source] [source] [source].

To reply, just mention @dosu.

---

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

[jhnns]

Making InferInput always return a deep readonly type (like wrapping with ReadonlyDeep) could break existing code and reduce flexibility, since many users expect to provide mutable data as input and only want readonly guarantees on output

This answer is kind of misleading. If InferInput returns a readonly type, it actually gets more flexible. That's because you can assign a mutable type to a readonly type, but not the other way round.

While playing in the TypeScript playground, I also observed an interesting unsoundness of TypeScript:

type ReadonlyTuple = readonly [boolean];
type ReadonlyObject = Readonly<{
    a: boolean;
}>;

type MutableTuple = [boolean]
type MutableObject = {
    a: boolean;
}

let readonlyTuple: ReadonlyTuple = [true];
let readonlyObject: ReadonlyObject = {a: true};
let mutableTuple: MutableTuple = [true];
let mutableObject: MutableObject = {a: true};

function takesReadonlyTuple(a: ReadonlyTuple) {}
function takesReadonlyObject(a: ReadonlyObject) {}

function takesMutableTuple(a: MutableTuple) {}
function takesMutableObject(a: MutableObject) {}

takesReadonlyTuple(mutableTuple); // Works as expected, you can assign a mutable type to an immutable
takesReadonlyObject(mutableObject); // Works as expected, you can assign a mutable type to an immutable

takesMutableTuple(readonlyTuple); // Correctly shows: The type 'ReadonlyTuple' is 'readonly' and cannot be assigned to the mutable type 'MutableTuple'
takesMutableObject(readonlyObject); // Does not show an error, but should? takesMutableObject might mutate the object

Playground

So maybe this whole problem is only related to tuple types.