Remove `enum` types

[scottanderson]

Description

1. Replace enums with strings unions.

export enum GameType {
  Singleplayer = "Singleplayer",
  Public = "Public",
  Private = "Private",
}
export const GameTypeSchema = z.nativeEnum(GameType);

becomes:

export const GameTypeSchema = z.union([
  z.literal("Private"),
  z.literal("Public"),
  z.literal("Singleplayer"),
]);
export type GameType = z.infer<typeof GameTypeSchema>;

2. Block enums with eslint:

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      // ban all enums
      {
        "selector": "TSEnumDeclaration",
        "message": "See https://www.youtube.com/watch?v=jjMbPt_H3RQ"
      }
    ]
  }
}

Justification

Enums do not behave as you might expect at runtime, because enums are not a native feature of javascript. The typescript compiler creates a strange looking object when you use the enum keyword:

And when you run this weird code, you get this exceptional result:

Things get a little bit better if you set the enum values to strings, but only if the keys and values match. If they do not match, zod will create types based on the key, but the values will actually be used, resulting in schema validation errors.

[Nephty]

I highly recommend Zod 👍 It has helped me greatly in the past

[scottanderson]

@ghisloufou volunteered for this

[Xzensi]

I don’t see the point of fighting the TypeScript compiler like this. This does not seem like valid reasoning to me at all, and frankly, all the comments in the video you linked disagree—with solid, practical justifications.

First, the idea that enums are problematic because the compiled JavaScript “looks weird” is irrelevant. You’re not supposed to poke around or manipulate the compiled output manually in the first place. That’s just not how TypeScript is intended to be used.

Based on the linked video the second point being that you can't use string arguments with Enums, but I'd hard argue that that's a very good way to turn your codebase into unmaintainable spaghetti. Only the consumers of enums are ever supposed to know what value an enum can have. Also with string literals sprinkled throughout your code, you lose any hope of safely refactoring or even grepping values without missing or breaking things.

Third, your suggestion to replace enums with unions completely changes the semantics. Unions are not enums, they don't behave the same way. Enums - unions. Doing what you suggest destroys your ability to use GameType.Public as a named constant.

This suggestion feels more like cargo cult avoidance of enums than a well-reasoned design decision.