Allow inferred object literal optional properties

[rtcpw]

🔍 Search Terms

"object literal", "object literal optional properties", "inferred object literal optional properties"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

With exactOptionalPropertyTypes, it becomes quite important to mark each property as optional via ?, | undefined, or both. We need an ability to mark object literal properties as optional.

📃 Motivating Example

The inferred object literals do not allow marking a specific property as optional. For example, the literal obj:

function getValue1(): string {
    return 'hello world';
}

const seed = Math.random();

function getValue2(): number | undefined {
    return seed > 0.5 ? 1 : undefined;
}

const obj = {
    prop1: getValue1(),
    prop2: getValue2(),
};

infers this type:

{
    prop1: string;
    prop2: number | undefined;
}

But there is no way to hint to the type inferer to mark the prop2 as optional. What I want is this inferred type:

{
    prop1: string;
    prop2?: number | undefined;
}

I propose the following syntax to achieve this:

const obj = {
    prop1: getValue1(),
    prop2?: getValue2(),
};

💻 Use Cases

1. What do you want to use this for?

I use the excellent zod library, and having the ability to create object literals with optional properties within transforms would allow me to create the types exactly how I need them to be while using the exactOptionalPropertyTypes option.

2. What shortcomings exist with current approaches?

It is currently not possible to conveniently create inferred optional properties without discarding the undefined union type from the property as well. Eg. this workaround will add the optional flag to the property, but it will discard the undefined union type:

const obj = {
    prop1: getValue1(),
    ...(getValue2() != null ? { prop2: getValue2() } : {}),
};

3. What workarounds are you using in the meantime?

const obj = {
    prop1: getValue1(),
    ...(getValue2() != null ? { prop2: getValue2() } : { }),
    ...(getValue2() == null ? { prop2: undefined } : { }),
};

This is obviously less than ideal due to having to repeat the code twice.

[MartinJohns]

I'm not sure I see the purpose behind this. The proposed object literals will always have prop2 set, so marking it as optional doesn't make much sense.

[jcalz]

I highly doubt TS is going to introduce new syntax for this use case. If this happened often enough to me where manually annotating the wider type became tedious, I'd write a helper function to widen from T to Partial<T> like

function partial<T>(t: T): Partial<T> { return t }

and then use it like

const obj = {
  prop1: getValue1(),
  ...partial({ prop2: getValue2() })
};

Playground link

[rtcpw]

I'm not sure I see the purpose behind this. The proposed object literals will always have prop2 set, so marking it as optional doesn't make much sense.

The main purpose is for libraries like zod (and others) that depend on the literal types to cascade through all their code. In zod, that literal object can be thought of as a template or factory definition and is used to create similar objects, and these new objects inherit the type defined by that literal object. So being able to decorate the factory object with additional type information and optionality starts making sense.

[rtcpw]

I highly doubt TS is going to introduce new syntax for this use case. If this happened often enough to me where manually annotating the wider type became tedious, I'd write a helper function to widen from T to Partial<T> like

Thank you, this is actually a nice workaround.

[MartinJohns]

In zod, that literal object can be thought of as a template or factory definition and is used to create similar objects, and these new objects inherit the type defined by that literal object.

As far as I know these libraries use a helper type to get the type described by the "factory object". Nothing prevents those libraries from providing an option to declare properties as optional, then evaluate it accordingly in their helper type and make these properties optional. I don't see the need for such a syntax (which would probably be very misleading and make people believe the property is unset when the value is undefined, which of course would not be the case).

[nmain]

The claimed use case confuses me because zod has a solution for this already:

Playground

import { z } from 'zod/v4-mini'
const schema = z.object({
  a: z.number(),
  b: z.optional(z.number()),
})
type S = z.infer<typeof schema> // { a: number; b?: number | undefined; }

If you use a zod-like approach, the object passed to z.object(...) has a much different type than the type that the schema represents, as its values are $ZodType<TProp> and not TProp, so a mapped type transform will be needed anyway, and the optionality can be handled there.

[RyanCavanaugh]

I agree the scenario is in fact well-handled by zod et al. The motivation to do a sort of property-level upcast makes some sense but I like the partial function (or even a generic one where you could do partial<"opt-prop1" | "opt-prop-2">(...) as a sufficient workaround unless another use case pops up to justify this.

[rtcpw]

The claimed use case confuses me because zod has a solution for this already:

Playground

import { z } from 'zod/v4-mini'
const schema = z.object({
a: z.number(),
b: z.optional(z.number()),
})
type S = z.infer // { a: number; b?: number | undefined; }
If you use a zod-like approach, the object passed to z.object(...) has a much different type than the type that the schema represents, as its values are $ZodType<TProp> and not TProp, so a mapped type transform will be needed anyway, and the optionality can be handled there.

You are assuming the simplest usage of zod. I am using zod to also rename/transform the object, and that's where I encountered this optionality issue:

const schema = z.object({
  a: z.number(),
  b: z.optional(z.number()),
}).transform((input) => ({
  c: input.a,
  d: input.b,
}));

type S = z.infer<typeof schema> // { c: number; d: number | undefined; }

@jcalz solution does help solve this:

const schema = z.object({
  a: z.number(),
  b: z.optional(z.number()),
}).transform((input) => ({
  c: input.a,
  ...partial({
    d: input.b,
  }),
}));

type S = z.infer<typeof schema> // { c: number; d?: number | undefined; }

However, creating an actual JavaScript function to work around pure typing issue feels to me like something is missing in the TypeScript expressiveness.

[MartinJohns]

You are assuming the simplest usage of zod. I am using zod to also rename/transform the object, and that's where I encountered this optionality issue:

const schema = z.object({
a: z.number(),
b: z.optional(z.number()),
}).transform((input) => ({
c: input.a,
d: input.b,
}));

type S = z.infer

I assume with your proposal you would write z.object({ b?: z.number() }) - if so, then your proposal wouldn't change anything about the outcome. The z.optional() already let's Zod infer the property as optional (as your suggestion would), but the optionality then gets lost by Zod in the transform (as it would be with your suggestion).

edit: I had a brain fart and didn't realize your suggestion could be applied to the argument provided to transform.

[rtcpw]

@MartinJohns zod already handles optionality well enough for the simplest use cases. I never intended the proposed feature to be used as z.object({ b?: z.number() }) because that would not allow zod to make any kind of optionality validation when actually processing the data. The proposed syntax would only change types but do nothing for validation, which is the whole point of zod.

It's the transform part where the problem and the proposed syntax play any role, and the motivation for the whole discussion. The transform part does not do any kind of validation anymore, and so it is the right place to decorate the literal type with optionality.

[guillaumebrunerie]

You are assuming the simplest usage of zod. I am using zod to also rename/transform the object, and that's where I encountered this optionality issue:

const schema = z.object({
a: z.number(),
b: z.optional(z.number()),
}).transform((input) => ({
c: input.a,
d: input.b,
}));

type S = z.infer // { c: number; d: number | undefined; }
@jcalz solution does help solve this:

const schema = z.object({
a: z.number(),
b: z.optional(z.number()),
}).transform((input) => ({
c: input.a,
...partial({
d: input.b,
}),
}));

type S = z.infer // { c: number; d?: number | undefined; }
However, creating an actual JavaScript function to work around pure typing issue feels to me like something is missing in the TypeScript expressiveness.

But it's not a pure typing issue, the two examples behave differently even in plain JavaScript.

The first one transforms an optional field b into an always present field d (which will be undefined if b wasn't present), while the second one correctly omits the field d entirely if b wasn't present.