Sorry, can you explain this more? I somehow still don't understand.

How is this different from a const object style enum? Or are you more referring to the sum type enum as the better choice here to avoid this.

Generally, if you remove an enum variant, the compiler should warn you if you've used it anywhere else (though of course it can't figure out a dynamic usage)... But this seems like a problem mostly for dynamic code, where you'd probably write some sort of Enum.parse() or Enum.from() static method anyway?

If I'm understanding your comment correctly, the real problem is that when you store the value, remove one, and try to read it back out into the enum it will fail - but in the code I've written so far trying to construct the the enum object almost always consisted of using a function to validate anyway, these days I use zod but before I'd write stuff like:

    function isEnum(obj: unknown): obj is Enum {
      return obj && typeof obj === 'string' && Object.values(Enum).includes(obj)
    }

My understanding of the comment is that it’s in the context of saving an enumeration-object into a database.

Like Typescript might (for example) represent enums as integers like 1, 2, 3... at runtime.

What happens if you decide to store a “delivery status” enum in a database? You would just be saving a number into the database, which can be hard to understand.

If it’s a string, then the value stored in the database is clearer and doesn’t depend on you being lucky with the Typescript compiler that the same enum type is compiled to the same integers after new releases.

I only realised this issue now, but it’s what I understood after reading that comment.

This is also another problem and a reason to strictly stick to string type unions, IMO.

There may be a really good use case for the enum type, but I think in most cases, string type unions are clearer, easier, and less prone to errors.

Yeah, one of the annoyances I have with using Enums, even in other languages, is that its serialised value isn't always obvious. Something like direction.NORTH could serialise into "NORTH" or some integer, depending on the language and the implementation.

I like Typescript's union of string literals approach because its serialised value is never in question. I know exactly what "NORTH" serialises to.

In Java it is de facto standard to serialize enums as string, with exception of JPA where you can explicitly tell if it’s a string or a number. It also supports exotic mappings via explicit declarations. Typescript should have implemented enums with union type under the hood, enabling the use of constants instead of strings when passing/checking values.

    but in the code I've written so far trying to construct the the enum object almost always consisted of using a function to validate anyway

It's exactly this problem and it's not obvious for someone choosing an enum type that the underlying implementation in JS is an object indexer.