If you truly don't care about the runtime representation, then it sounds the idiomatic JS/TS construct you actually want is Symbol()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://www.typescriptlang.org/docs/handbook/2/everyday-type...

Symbol is an extremely heavy hammer. It's also difficult to use correctly.

What value do you think it offers here?

I brought up symbols because ameliaquining's declared requirements match symbols to a T:

> I don't want to think about the question of runtime representation; I just want a set of arbitrary symbols that are different from one another.

I wouldn't know how such requirements translate into value for her. Personally, when I need a set of type-checked fixed values, I favour string literal unions because a readable runtime representation eventually comes in handy.

The only time I recall using symbols was in order to have a "newtype"-like construct, which is a different thing entirely.

I agree that it might have been better for that to be the TypeScript idiom, but it's not, due to the longer-standing popularity and concision and language-level support for enums. (Which couldn't have originally been designed to be lowered to symbols, because at the time symbols weren't widely-supported enough.)

Symbols are very well supported in TS today. You even get proper type enforcement and intellisense when using symbols as the names of methods and properties, for instance. Whether you should use them for enum-like purposes or not has more to do with how you want to use the values though. For instance using symbols for defining numeric protocol values doesn't make sense. Same for HTTP methods, where you are always ultimately passing a string down to the http client/server interfaces

Good point, I'm mostly doing web stuff so I always think about how something looks in JSON in the network panel of my browser.

If you just use the value within your code the runtime representation does not matter, you're completely right.