Properties in object literal key completion list aren't filtered when a prior argument supplies a mapped type key

[simonhaenisch]

• VSCode Version: 1.41.0
• OS Version: macOS 10.14.6

Steps to Reproduce:

>> Playground Link

interface CustomElements {
    'component-one': {
        foo?: string;
    },
    'component-two': {
        bar?: string;
    }
}

interface Options<T extends keyof CustomElements> {
    props: CustomElements[T];
}

function create<T extends keyof CustomElements>(name: T, options: Options<T>) {
    return { name, options };
}

create('component-one', { props: { /* trigger intellisense here */ } });

const opts: Options<'component-one'> = {
    props: { /* and here */ }
}

The type of props in the create call is correctly narrowed down to CustomElements['component-one'] by the type system, however Intellisense suggests the props of all fields of CustomElements:

This does not happen when creating an object of that type:

Does this issue occur when all extensions are disabled?: Yes

[RyanCavanaugh]

@andrewbranch I seem to recall a duplicate of this, but searching is impossible

[andrewbranch]

This was originally an unintended consequence of #32100/#33937, and while following up with #34855, spent a few days trying to come up with a way to get rid of these invalid entries without un-fixing #30507.

I talked to @DanielRosenwasser about weighing trade-offs, and @weswigham about other possible implementations, but I haven’t figured out a way to do this without speculatively checking possible future program states, which I think is prohibitively expensive. @DanielRosenwasser do you still feel the current behavior is an acceptable trade-off? I’m still not very happy with it, but not sure whether a much better solution is in sight.

[simonhaenisch]

Ok that issue title makes more sense 🤓 Just want to add that the exact same thing also happens when the mapped type key is another field of the same argument (instead of a prior argument), i. e.

interface Options<T extends keyof CustomElements> {
    name: T;
    props: CustomElements[T];
}

create({ name: 'component-one', props: { /* trigger intellisense here */ } });

the current behavior is an acceptable trade-off?

Not sure why providing the programmer with invalid field names would be an acceptable trade-off?

Anyway, thanks for looking into this!