Type.Partial/Pick/Omit silently discard outer Transform — should this throw instead?

[yiidtw]

Hi Haydn — as per our discussion over email, I'm opening this issue here for further conversation. Thank you for taking the time to explain the design rationale, really appreciate it.

Behavior

Type.Partial() silently discards TransformKind when applied to a schema with outer Type.Transform(). Same for Type.Pick(), Type.Omit(), and Type.Composite().

I understand that interior Transform (applied to individual properties like Type.Transform(Type.String())) is retained through Partial — this is great. The issue is specifically about outer/structural Transform.

import { Type, TransformKind } from "@sinclair/typebox";
import { Value } from "@sinclair/typebox/value";

const Schema = Type.Transform(
  Type.Object({ bio: Type.String() })
)
  .Decode(v => ({ bio: v.bio.replace(/<[^>]*>/g, "") }))
  .Encode(v => v);

console.log(TransformKind in Schema);                // true
console.log(TransformKind in Type.Partial(Schema));   // false — silent discard

Value.Decode(Schema, { bio: "<b>hi</b>" });
// => { bio: "hi" }  — Transform active

Value.Decode(Type.Partial(Schema), { bio: "<b>hi</b>" });
// => { bio: "<b>hi</b>" }  — Transform silently gone

I also checked typebox 1.x — Partial() discards ~codec the same way.

Question

Type.Intersect() already throws when it encounters Transform (as of 0.34.48). Would it make sense for Partial/Pick/Omit to do the same? A throw would:

• Make the behavior visible (no silent surprise)
• Be consistent with Intersect's approach
• Guide users toward the interior-Transform pattern you recommended

Best Regards,
YD

[sinclairzx81]

@yiidtw Hi, thanks for re-submitting.

Type.Intersect() already throws when it encounters Transform (as of 0.34.48). Would it make sense for Partial/Pick/Omit to do the same? A throw would:

I think this is worth consideration and will likely be implemented. Unfortunately, there's not too much I can do on the 0.34 or 1.1 version lines without introducing a breaking change. But will look at implementing the Codec/Transform assertion on the next minor version(s) (0.35.x and 1.2.x respectively). I do think this is a good idea.

Related: sinclairzx81/typebox#1448 (comment)

Will keep this issue open for now and review implementation on the next around of updates.
Thanks again
S

[yiidtw]

Thanks Haydn — really appreciate the thoughtful response on both the email thread and here.

The plan for 0.35.x / 1.2.x sounds right. Agreed that throwing would be a breaking change for the current lines, and keeping 0.34.x / 1.1.x stable makes sense.

And good to see SimenB already raised something similar in #1448 back in December — nice to know the direction has broader support. Happy to test against the next minor when it lands if that would help.

Thanks again for the engagement.

YD