Bad type checking enum based objects

[picasocro1]

Bug Report

🔎 Search Terms

type checking enum based objects
type checking enum params

🕗 Version & Regression Information

Tested on versions (4.6.2, Nightly - v4.7.0-dev.20220405) on playground all failed.

⏯ Playground Link

Playground link with relevant code

💻 Code

enum Locale {
  en_US = 'en-US',
  de_DE = 'de-DE'
}

type AtLeastOne<Obj, Keys = keyof Obj> = Keys extends keyof Obj ? Pick<Obj, Keys> : never
export type NonEmpty<T> = Partial<T> & AtLeastOne<T>

type TranslationBase = {
  [locale in Locale]: string
}

type Translation = NonEmpty<TranslationBase>

// @ts-expect-error
const badTranslationBecauseItsEmpty: Translation = {}

const correctTranslationBecauseItHasAtLeastOneKey: Translation = {
  [Locale.en_US]: ''
}

const shouldCreateCorrectTranslationButHasUnexpectedError = (locale: Locale): Translation => ({
  [locale]: ''
})

🙁 Actual behavior

TS produces the error:

Type '{ [x: string]: string; }' is not assignable to type 'Translation'.
  Type '{ [x: string]: string; }' is not assignable to type 'Partial<TranslationBase> & Pick<TranslationBase, Locale.de_DE>'.
    Property '"de-DE"' is missing in type '{ [x: string]: string; }' but required in type 'Pick<TranslationBase, Locale.de_DE>'

🙂 Expected behavior

No errors should be produced. In function, we expect locale which is an enum (not string) and TS prevents us from using something different. Thus the returned object should be of an appropriate Translation type.

[MartinJohns]

Simplified example:

type Translation = { [Locale.en_US]: string } | { [Locale.de_DE]: string }
declare const locale: Locale;

const translation: Translation = { [locale]: '' }

[jcalz]

Duplicate of or strongly related to #13948

[RyanCavanaugh]

The underlying problem is that we don't have any accurate + performant representation of the type of { [locale]: '' }

It's not Record<Locale, string> because that type implies that it has both properties, when it very obviously does not.

It's not Partial<Record<Locale, string>> because that type includes the empty type; this representation would yield the same error as the current implementation (just with a different message).

It's something like { Locale.en_US: string } | { Locale.de_DE: string } except that people can and do write code like { [locale1]: '', [locale2]: '', [locale3]: '', ... (ten more) } and we can't go around creating k ** N possible inhabitant types whenever we see a computed property name.

[edrennikov]

I'm not sure if it is related, but sounds so. This code:

enum E {A, B};
const x = {a: E.A};
const y: {a: E.A} = x;

generates an error:

Type '{ a: E; }' is not assignable to type '{ a: E.A; }'.
  Types of property 'a' are incompatible.
    Type 'E' is not assignable to type 'E.A'.(2322)

which sounds strange, because x obviously has correct type and can be assigned to y.
But if written this way:

enum E {A, B};
const x = {a: E.A as E.A};
const y: {a: E.A} = x;

then there is no error.

[RyanCavanaugh]

@edrennikov different issue; the problem is that it's legal for you to write

enum E {A, B};
const x = {a: E.A};
x.a = E.B; // <- anywhere in your program
const y: {a: E.A} = x; // <- now unsound

You can also use const x = { a: E.A} as const; to prevent that from happening

[edrennikov]

Thank you, now I understand it!