Should we be able to provide an enum when using omit?

[LiamDotPro]

Search Terms

Omit Enums, Can I use Enums with Omit utility types

Suggestion

I would like to be able to pass in an enum to the utility type Omit as the second argument.

Use Cases

Currently you can only provide strings when using an Omit I would like to also be able to provide an Enum so I can notify future developers of the keys that are allowed to be Omitted. It would also make defining different types simpler because I can use code completion without having to fully type out the string.

Examples

interface Todo {
  title: string;
  description: string;
  completed: boolean;
}

enum TodoPossibleKeys {
    TITLE='title',
    DESCRIPTION='description'
}

type TodoPreview = Omit<Todo, TodoPossibleKeys.DESCRIPTION>;

const todo: TodoPreview = {
  title: "Clean room",
  completed: false,
};

todo;

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.

[jcalz]

enums are weird. The subtype/supertype relationship between enum values and their corresponding string or numeric literals is somewhat unsound (especially for numeric enums).

Personally I try to stay away from enums because of this. It would be great if enums were made more sane, but existing real-world code relies on the current implementation, so it's hard to imagine a fix for this that doesn't break someone. This also implies that I wouldn't be so quick to put that ☑ on "This wouldn't be a breaking change in existing TypeScript/JavaScript code" in the issue template.

Assuming this doesn't change anytime soon, my advice follows:

---

If you really want to use an enum, you should probably treat the values as opaque and only access them through their keys. Meaning you should be able to change the values without your code breaking (it's quite possible that doing that would break some upstream/downstream code that cares about the specific values, but you should treat them as opaque):

enum TodoPossibleKeys {
    TITLE = 'title', // only mention 'title' here
    DESCRIPTION = 'description' // only mention 'description' here
}

interface Todo {
    [TodoPossibleKeys.TITLE]: string;
    [TodoPossibleKeys.DESCRIPTION]: string;
    completed: boolean;
}

type TodoPreview = Omit<Todo, TodoPossibleKeys.DESCRIPTION>;

const todo: TodoPreview = {
    [TodoPossibleKeys.TITLE]: "Clean room",
    completed: false,
};

On the other hand, if you really care about the particular values, then maybe enum is the wrong tool and you should just string literal types directly:

type TodoPossibleKeys = 'title' | 'description'

interface Todo {
    title: string;
    description: string;
    completed: boolean;
}

type TodoPreview = Omit<Todo, "description">;

const todo: TodoPreview = {
    title: "Clean room",
    completed: false,
};

or you can make an enum-like thing if you really like that syntax without the weird supertype/subtype behavior:

// enumlike thing
namespace TodoPossibleKeys {
    export const TITLE = 'title';
    export type TITLE = typeof TITLE;
    export const DESCRIPTION = 'description'
    export type DESCRIPTION = typeof DESCRIPTION
}
type TodoPossibleKeys = typeof TodoPossibleKeys[keyof typeof TodoPossibleKeys];

interface Todo {
    title: string;
    description: string;
    completed: boolean;
}

type TodoPreview = Omit<Todo, TodoPossibleKeys.DESCRIPTION>;

const todo: TodoPreview = {
    title: "Clean room",
    completed: false,
};

Any of those approaches should resolve the issue you're having without waiting for TypeScript to address the quirky behavior of enum.

Playground link

[LiamDotPro]

@jcalz This is a wonderful answer and I wasn't aware of the two approaches you mentioned, having the evening to think over it I'm now starting to wonder if enums really are such a nice choice. Thanks for the write up!