Comparability/type assertion failure when using enums and underlying literals

[DanielRosenwasser]

The regression reported here can be traced back to #53192. The minimal~ repro case for it is this:

enum AutomationMode {
  NONE = "",
  TIME = "time",
  SYSTEM = "system",
  LOCATION = "location",
}

interface ThemePreset {
  id: string;
}

interface Automation {
  mode: AutomationMode;
}

interface UserSettings {
  presets: ThemePreset[];
  automation: Automation;
}

interface ExtensionData {
  settings: UserSettings;
}

export function getMockData(): ExtensionData {
  return {
    settings: {
      presets: [],
      automation: {
        mode: "",
      },
    } as UserSettings,
  }
}

TS playground

Originally posted by @Andarist in #53192 (comment)

[fatcerberus]

Isn't it intentional that string literals are not assignable to string-based enums, even if they match one of the enum members?

[Andarist]

It's about comparability and it seems that this type of conversion is valid in such a context, for example, this is OK:

const foo = "" as AutomationMode

[fatcerberus]

Ah, I missed the type assertion as UserSettings so it just looked like an assignability failure, which was expected.

[ahejlsberg]

The fix here is to exclude the comparable relation from the optimization in #53192. I will put up a PR.