add stricter Omit helper type

[seansfkelley]

Search Terms

omit strict

Suggestion

The new Omit type does not restrict the omitted keys to be keys actually present on the given type. There should be some avenue to express "omit, but only with keys that are present", likely either a change to Omit or some other Omit-like type.

Use Cases

Copied from pelotom/type-zoo#31.

The benefit that a stricter type has is primarily:

• Preventing typos.
• Allowing the compiler to pick up on rename refactors automatically.

Currently, permissive Omit acts as a "barrier" that prevents rename refactors from passing through, which means that any such refactor generates whole bunches of errors that have to be manually fixed. If the field in question is optional, this can actually introduce bugs.

And some further color:

I generally use Omit with string literal unions (as opposed to, say, generic types that extends string), because I often use them for defining higher-order React components that wrap another component except for this one prop. As such, in my use case, I never want a permissive Omit.

Examples

interface ImplementationDetailProps {
  publiclyVisibleFoo: Foo;
  filePrivateBar: Bar;
}

class ImplementationDetail extends React.Component<ImplementationDetailProps> { ... }

export type PublicProps = Omit<ImplementationDetailProps, "filePrivateBar">;

export class Public extends React.Component<PublicProps> { ... }

Checklist

My suggestion meets these guidelines:

• 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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[sindresorhus]

I was disappointed when I saw that the Omit type added in #30552 was not the strict one suggested in #30455, and what most third-party type libraries provide. Like @seansfkelley mentioned, there are many benefits of making it strict. One additional benefit is the ability for everyone using Omit in these type libraries to use the built-in one instead. This will not be possible if the built-in one is not strict.

// @BendingBender @CvX

[nmain]

Currently, permissive Omit acts as a "barrier" that prevents rename refactors from passing through

Could this be fixed instead?

[seansfkelley]

Currently, permissive Omit acts as a "barrier" that prevents rename refactors from passing through

Could this be fixed instead?

That would help a lot, I think, but doesn't catch cases where someone does a manual refactor or just outright typos a field name and ends up exposing the wrong type to a consumer (i.e., a type that has fields that should not be visible).

Edit: I will say, I actually don't understand the use-case for permissive Omit at all -- I've never wanted it, but that might be a function of the fact that I'm not generally juggling generic extends string omits (e.g. type Foo<T extends string> = Omit<Bar, T>) but rather literal omit (e.g. type Foo = Omit<Bar, "field">).

[DanielRosenwasser]

It seems like the constrained Omit type is going to make at least half of users unhappy based on declarations within DefinitelyTyped. We've decided to go with the more permissive built-in which your own constraints can build on.

[sindresorhus]

I wish I hadn't encouraged opening this issue in the first place. It just made the situation worse than before as the Omit name is now taken by TS, so we have to rename our strict versions to prevent confusion...

[SamVerschueren]

It seems like the constrained Omit type is going to make at least half of users unhappy based on declarations within DefinitelyTyped.

And now half of the users are unhappy because it's loose. I totally understand that decisions like this are tough, but you can't make everyone happy. Sometimes you have to make people unhappy for the greater good. And in my opinion, strict typing is the greater good.

The current situation is that everyone is still using a custom Omit, e.g. StrictOmit which again should be defined everywhere. Hence, we're back to start.

[andyfleming]

I like having a loose Omit option available, but I agree it would be nice to see Omit stay consistent with how the community uses and understands it today. Providing both seems like a win-win.

Maybe we could find an alternate name for it?

• OmitIf
• Exclude
• Remove
• Without