Omit outputting incorrect types for types with mixed [key: string]: string | undefined and defined field types

[james-reed-toshi]

Bug Report

Using Omit and [key: string]: string | undefined together can result in Typescript not preserving the types of fields on the original type. Playground link here to display the issue: playground link for issue here

The issue is that the fields that were previously defined as strings, are now returning as string | undefined, even though there's no reason they should, type-wise. If you remove the [key: string]: string | undefined the problem goes away, and typescript is obviously clever enough to know that the fields line1, line2 and postcode are just of type string, not string | undefined.

🔎 Search Terms

omit, omit undefined

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Omit

⏯ Playground Link

Link given above

💻 Code

interface Address {
    [key: string]: string | undefined;
    line1: string;
    line2: string;
    postcode: string
}

interface Parent {
    id: string;
    party: boolean;
    address: Omit<Address, 'line2'>;
}

const parentFirst: Parent = {
    id: '',
    party: false,
    address: {
        line1: '',
        postcode: '',
    },
};

const finalAddress: Address = {
    line1: parentFirst.address.line1,
    postcode: parentFirst.address.postcode,
    line2: '',
}
  
// (property) Address.line1: string
// Type 'string | undefined' is not assignable to type 'string'.
//   Type 'undefined' is not assignable to type 'string'.(2322)

// Same error happens for poscode

🙁 Actual behavior

Omit does not preserve the types of the named fields

🙂 Expected behavior

Omit should preserve the types of the named fields

[MartinJohns]

#45367 (comment)

[james-reed-toshi]

Oh right, ok. Would adding this

type FieldTypePreservingOmit<T, K extends keyof any> = { [P in keyof T as Exclude<P, K>]: T[P] };

as a type in my codebase be the best course of action in this case? It seems to preserve the type of the fields. In fact, if this preserves the types of the fields, why is this not how Omit is coded? Would be interested to know why this is desired behaviour.

[RyanCavanaugh]

why is this not how Omit is coded

Omit is a type alias for a thing whose code you can read; it isn't a higher-order operation that understands what it's doing at a higher level.

type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;

It's generally pretty hard to work with types that have index signatures along with their declared types; I would rewrite this as

interface Address {
    line1: string;
    line2: string;
    postcode: string
}

interface Parent {
    id: string;
    party: boolean;
    address: Omit<Address, 'line2'> & { [key: string]: string | undefined };
}

[james-reed-toshi]

@RyanCavanaugh This is unfortunately a more legacy codebase and I can't remove the index signature without a lot of work elsewhere.

[james-reed-toshi]

Omit is a type alias for a thing whose code you can read; it isn't a higher-order operation that understands what it's doing at a higher level.

I understand that, but if it can do that and do better for the user, what's the downside with defining it as I did above with FieldTypePreservingOmit?

edit: Please understand I'm asking this from a position of ignorance, not a position of 'I think I could do better' :) dont want you thinking just because I've put an issue in that I know better than the entire TS team 😂

[RyanCavanaugh]

Ah, good question.

FieldTypePreservingOmit uses the key remapping feature that didn't exist when Omit was written, and changing the definition of Omit after the fact would be a breaking change. One of the reasons we don't like adding type aliases to the built-in lib -- we can't "upgrade" them!

[JamesZoft]

Aha, that makes sense! Is there a way, then, that I can propose this as an upgrade to Omit for v5 @RyanCavanaugh ?

[RyanCavanaugh]

We don't issue large breaking changes, regardless of version numbers, unless there's a very identifiable concrete upside. I don't think tweaking Omit for this scenario would meet that bar.

[JamesZoft]

That’s unfortunate - how would I go about overriding Omit with this improved version then? Thanks, James

…

Sent from my iPhone

On 23 Jun 2022, at 18:14, Ryan Cavanaugh ***@***.***> wrote:  We don't issue large breaking changes, regardless of version numbers, unless there's a very identifiable concrete upside. I don't think tweaking Omit for this scenario would meet that bar. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[RyanCavanaugh]

--noLib + provide your own copies of the lib files

[JamesZoft]

I see - is there no way to override it in a namespace like you can with other types in libraries?

…

Sent from my iPhone

On 23 Jun 2022, at 20:19, Ryan Cavanaugh ***@***.***> wrote:  --noLib + provide your own copies of the lib files — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[RyanCavanaugh]

You can lexically shadow it (including at module scope), but you can't globally clobber it

[JamesZoft]

So I’d need to define/import the type override in every file where I want it?

…

Sent from my iPhone

On 23 Jun 2022, at 22:54, Ryan Cavanaugh ***@***.***> wrote:  You can lexically shadow it (including at module scope), but you can't globally clobber it — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.