TypeScript enums: use cases and alternatives

I think they also haven't gotten very much attention in the last few years as new features have been added. Nine times out of ten, if I hit a weird case where TS doesn't understand some type that it really seems like it should understand, it involves an enum. And if I rewrite the enum as a union type and update the other code that uses it, my issue goes away.

I agree they should just formally deprecate it.

They still make sense in terms of clarity, readability and reusability. I use enum every time there are more than 2 entries -- literal types and "as const" are just ugly in comparison.

Not to mention that you can add documentation to each of the entries.

I wonder if there's a guide of recommendations about typescript now deprecated features, and its modern equivalents.

Changing values (after a change in an external interface), tracking use and renaming is harder in the first case. In the second case, the code can change the value at runtime.

> Enums is going to make your TypeScript code not work in a future where TypeScript code can be run with Node.js

Apparently they're planning on adding a tsconfig option to disallow these Node-incompatible features as well [1].

Using this limited subset of TS also allows your code to compile with Bloomberg's ts-blank-space, which literally just replaces type declarations with whitespace [2].

[1] https://github.com/microsoft/TypeScript/issues/59601

[2] https://bloomberg.github.io/ts-blank-space/

> in a future where TypeScript code can be run with Node.js

FYI, this is now. Node 23.6 will just run typescript files than can have their types stripped https://nodejs.org/en/blog/release/v23.6.0#unflagging---expe....

There is a seperate --experimental-transform-types flag which'll also transform for enums, but no idea if they ever intend to make this not experimental or unflagged.

That's a stage 1 proposal that has barely gained any traction since its release. In fact it hasn't been updated for quite a while (with "real" content changes). I wouldn't make decisions for my current code based on something that probably will never happen in the future.

https://github.com/tc39/proposal-type-annotations/commits/ma...

I understand, but what if I want to use the enums the way they are used in C, as a label for a number, probably as a way to encode some type or another. Sum types of literal numbers are not very practical here because the labels should be part of the API.

Maybe argue for enum being added to ecmascript instead?

You're correct. Nodejs can already run typescript code directly but it only does type stripping so it won't work with enums or namespaces which need additional code generated at build time.

Often, I find myself in need to find all references of "Active" from your example, which doesn't work with union values. This looks like a LSP limitation. Of course, you can move assign values into consts and union these instead. But that means you are half way there to custom run-time enums, and all the way after you wrap the consts with an object in order to enumerate over values at run-time.

Agreed. Its one of my major annoyances with Relay, is that it generates enums.

> no private properties

Private properties have been in the works for the last 7-8 years, and were officially added three years ago.

Re: __proto__, it's addressed in TFA

> Note that __proto__ also exists as a getter and a setter in Object.prototype. This feature is deprecated in favor of Object.getPrototypeOf() and Object.setPrototypeOf(). However, that is different from using this name in an object literal – which is not deprecated.

I agree; I'm in FAANG and it's even encouraged in my group. They are super easy to construct and work with and we've yet to encounter any side effects of using them despite our millions of customers world-wide.

Maybe people should become familiar with Grug: https://grugbrain.dev/

I'll take the t-rex.

> apex predator of grug is complexity. complexity bad. say again: complexity very bad. you say now: complexity very, very bad. given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

I've had issues with enums on at least three occasions, but I cannot remember what they actually were - but every time I've tried using them, I've regretted it.

I can't remember the last time I needed enums. Usually they fall out of the code in one way or another

    // in some util.ts or helpers.ts
    export function keysOf<T extends string>(obj: { [k in T]: unknown }): readonly T[] {
       return Object.keys(obj) as unknown[] as T[];
    }

    //---

    const kOperationsFunctions = {
       add(a: number, b: number) { return a + b; },
       subtract(a: number, b: number) { return a - b; },
       multiply(a: number, b: number) { return a * b; },
       divide(a: number, b: number) { return a / b; },
    };
    const kOperations = keysOf(kOperationsFunctions);
    type Operation = (typeof kOperations)[number];

In typescript, some types are values. Typescript treats enums as types, but they're secretly values. Classes are types and values.

Same, I have use enum strings for years and never had an issue.

Yeah, people arguing against enums in this thread are doing a really bad job. I haven't seen a single compelling argument.

Exactly what I do, but I've found that I almost always will add a few things that come in handy.

    export const SMS_TYPE = Object.freeze({
        BULK: 'bulk',
        MARKETING: 'marketing',
        PIN: 'pin',
        SIGNUP: 'signup',
        TRANSACTION: 'transaction',
        TEST: 'test',
    } as const);

    export const SMS_TYPE_LIST = Object.freeze(Object.values(SMS_TYPE));

    export const SMS_TYPE_SET = Object.freeze(new Set(SMS_TYPE_LIST));

    export type SmsType = typeof SMS_TYPE[keyof typeof SMS_TYPE];

why repeat the names?

    // put this in some util.ts or enum.ts file
    function makeEnum<T extends readonly string[]>(keys: T) {
        return Object.fromEntries(keys.map((x) => [x, x])) as {
            [K in (typeof keys)[number]]: K
        };
    }

    const SMS_TYPES = makeEnum(['bulk', 'marketing', 'pin', 'signup', 'transaction', 'test'] as const);
    type SMS_TYPE = keyof typeof SMS_TYPES;

I’ve also seen them behave very weirdly and inconsistently. There have been cases when I’ve had to explicitly declare that a value has an enum type, even though its type is already one of the enum’s values (and not a literal of the same value, but literally straight from the enum itself).

From what I can tell, they were an early addition from back before TS had unions, and it feels like they live in their own world within the type system. I would go further than saying you should disallow them with a linter, and say that they should be deprecated in the language. Right now they’re just a foot gun for new TS devs.

Are all strings under a certain length interned?

> I never took Node seriously for backend work—it was always something I reluctantly touched for client-side stuff

That was my initial assessment as well. Anything JavaScript related I stood clear and far away from using it anywhere near backend systems and relegated it into the list of non-serious technologies to stay away from.

> Over time, though, it’s added so many crufts and features that these days, I shudder at the thought of reading a TS expert’s type sludge.

TypeScript just repeated the same issues as CoffeeScript and both JS and TS are just as bad for software anyways.

Go and Kotlin have much better type systems, but the rest of the JS ecosystem just reeks with immaturity.

TS type sludge is required to make the JS underneath workable.

I'd welcome TS type system in Python, mypy and co. should steal it outright.