[ricardolopes]

Relying on hacks for production code is usually a red flag/code smell that indicates there was probably a better alternative. `string & {}` definitely feels like one of those hacks.

As an alternative, wouldn't it be better to map the list of supported values in a structure like an enum?

Example:

```

enum HelloWorldValue {

  Hello: 'hello',

  World: 'world'

}

const value = HelloWorldValue.Hello

```

And now you can call that enum when declaring a variable value and get its contents in autocomplete. As a nice bonus, because these are references and not strings, you can ask your IDE for all places instantiating those values, which can be a life saver.

[WirelessGigabit]

This is what happens when you are building rules are around an existing system versus the other way around.

In another language you have a value of type String which can take any value, might crash, might not, when you give it a color value.

And then you have a set of items like you described, which are convertible to String (or are a string, like your enum).

In fact, the receiver property probably shouldn't even be String, but typeof Color, which can be constructed through a method/constructor that ensures the String input is a valid format.

Because which color is "XXXXXX"?

[3836293648]

Based on the last time I played with thml colours, probably red

[shortrounddev]

It's also a lot of effort for a language which seems to be incapable of runtime type checking. Typescript is a glorified linter

[pvinis]

> This is what happens when you are building rules are around an existing system versus the other way around.

exactly right!