Better inline type annotations

[johnfn]

Say I'm writing some code like this:

type MyKeyValues = "a" | "b" | "c" | "d";
const myNestedObject = {
    foo: {
        "a": 1,
        "b": 2,
        "c": 3,
    },
    bar: 5,
    baz: 6
};

I would like myNestedObject to understand that foo is type { [key in MyKeyValues]: number }, so that the type of myNestedObject is fully inferred. I currently have a few suboptimal solutions:

1. Duplicate the entire structure of myNestedObject like so:

    const myNestedObject: {
        foo: { [key in MyKeyValues]: number },
        bar: number,
        baz: number
    } = {
        foo: {
            "a": 1,
            "b": 2,
            "c": 3,
        },
        bar: 5,
        baz: 6
    };

I don't like this because it is a violation of DRY. If I want to add new keys to myNestedObject, I have to add them twice.

2. Inline type conversion

    const myNestedObject = {
        foo: {
            "a": 1,
            "b": 2,
            "c": 3,
        } as  { [key in MyKeyValues]: number },
        bar: 5,
        baz: 6
    };

This is nicer on the eyes, but not nicer on the type checker. Now we don't get any error that "d" has been omitted from foo.

Summary: I would like some of syntax to give a type to the inner object.

[johnfn]

To me, the obvious solution seems to give an error on { "a": 1, "b": 2, "c": 3 } as { [key in MyKeyValues]: number } because the object literal does not satisfy the type.

(But it seems like every time I propose what I believe is the obvious solution around here, someone tells me why it's horribly wrong, so I leave this as a separate comment to not distract from the main proposal 😉 )

[normalser]

Something similar in here: #7481 (comment) and #11216

[aluanhaddad]

I really like @wallverb's suggestion. Also it would not limit this to mapped types.

[zpdDG4gta8XKpMCd]

also consider #13082 (automated extracting an interface from an object literal)

[aluanhaddad]

@Aleksey-Bykov #13082 is a great but they serve different purposes. Both would be valuable.

[RyanCavanaugh]

I think #7481 is the preferred answer here