Intellisense provides different suggestions on autocomplete when using indexed access or dotted access

[alexandercerutti]

🔎 Search Terms

"autocomplete suggestions intellisense differences between indexed access and dotted access"
"indexed access vs dotted access suggested properties"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about

I tested it in TS Playground with Nightly and TS 5.2.

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.0-dev.20231013#code/PQKhCgAIUhxB5AggGQFyQOYEsBuBTAO0gEMjCBXAW0gHsAzSABxoGcWsAjAGz0j3wIAXFgBpIAd17jSgyIJpQYxNlgxEWNSr36FZjYgE8uNYgBM5Bxr3mQNW2g0EALbQOEA6RZC8AVF5AAnPBZZFicaci5zDDxZYkxCPACsAGNIACIAUTd0pkNjMxIVNTxTT2hIAHU8MWdCMTCIqMgOXmJuaxpILQCYlppnOX8QgPIUwXIgli9Sc1aSDsgsIjpyAnGsGgIWIeJZchZeGIIk1J2uLABraycsHa3eVuNxLxsaDkFiZaHefSMTcwhYgBQTLDCQOgBTQ-PhuCxWcogYDgcCmPApLjA3irdagrYQrBcQRJADCB3klGyugACvkAQAxGgBKlCAA8Pj4AA9iQRTDsSdSWcIAHwACjoTKF6B8AEp0PAOIcAjh2jxWQKhSwALLERgAbR8AF1hSjQBAKlqsJRUpcwYFOQArHY2Yg4GhYcxoqy8wgpAxLSjMEGKZHgQSWXgKpUqjqsgAawsgAF5IABvcAASBY5EVKWSrVFcsgUaSMbVCfAAF8ANymsCQZCxADkO1a2CISJRFGoGrcO3TGZJyAAkiSANLJjIYm3pESZ6nIRAATUn6UYmIMs8zJMQADkF8vVylSOvDFuMwel8Pd7BV6eDGDz9TEABVADKmTvxAOeHPmQASv+8D-quSRQgEf67gAIpkUGgT6pjnsgSBQW+PiIP+HIpukBSmG+nwgue-6ID4mQkgAEnusCfthAR7OiTikDE56VIgw4+Net7YdIWCggQGDnh+mRjpxq6HHgtr8YJmTCbBYl4BJpTnhxWqZC+1JQSRNEZKCWjkIwpj0eeABq8DIC+qkUVR2npG6XBUAxTG-nOGZQS+xEcfAu5WTeNmmJMeybOsjH8c5maIFBUE+MR46rmYpiCHRKSXH+WpvlxGR4JQLACS5l4AEKIOOAD6+WZLA17FZRyCkXB2H3hwxDJfleDtuRxBEkpLloRhPjFSpmTFYgxlsYu+XIDZQIgj4Vp4IgKqEqqYWDl5pG7n1PWkcVPnUXVU5bDygj4fRJIhTEiEua+UHDvAxWXsV-7DrA5F9UVACKL7Dv+cnYd+pibNSG7-qoTiCIgKQAI7kFgQQXZmm1vsV6maaRYmfMIL4GUZc6VqawCQLS-xmDsjH4C0ClEEEp4pKUEJMjCVNQgAtMehxiBw5CyHU-qmF0BADN0ezEgEgQg7I-PiJ4yzC3QTW8AKOqMFYpiammmZ6r2ugsO4mRpbAhroGslwSwQ1beBmGuCn27huR5N3eZRvkG5ARsm7WFua0I2umeZlmO9RzuuzQ4im+rnseANyNaYHBDG8Hoce1bWs64BwEx3HIfu5bmruB5ZH+5k6du2HSde+4EVRTFY5F-HWfh9rJKrZk63FZtg07bBNeZyXOc9Zh-XDqpQ0jcOY0TV3CfZ9bBVFWOpXlZV1W1RPdelx4CNIxp0eG7HxeJznV03Xdi5Lg9T0vUNJIfV9nc7xnk-1+4QkiTeK899bz+3y7u+11WdbmjAPwdwliiAcJAFIEQAhsxhCwYg9h6BeC8AAAxQV4f86ImSmFZJkTkGJyBonVGvUB1wDD0EgArXUytNTCjEEKE0FQUFIJDCicMVhyHUhfAQSglDSiqxTAOPUE5vg4LwQQ+uYgSFkIoUrXhfZhTOyFLWGsXZORBi5hGdhmpFaTmkVQvskAABk7DOHcJkSrPstZwB4FUUydRbCBQlmVEtPhasLZCKIJIhg9dFbO0cWWPAhCtG6kEcaJRlizReEbIIFs4Cgj0VoJMWgHAHTolkOIXiTgEki1MYwMEXhWiCEkIQPgBAqCQBITsWYSToxLW1sw1E6JMRBHAVsEIsJdB+NqegBxipSzOIsf-Lwu5g60G9DCaWeAuAXEONsXg+NvzyAgYGHgeIiBaFKbQIgzhgHWMYFMdg+IOA83dPxfozhUCIIYagioOghCdI6HUq5TCKgzF5JcmAjCvC3MEPcngLA9TpHSIaZBKCAAF7zvAVD8NoVRqTaZTEiLIYBzg9hLC5i4f0jRIjmD2TQHAHprDiC6P9OgdAki6C8NmXpwgwEpHCKkYIkBRTEhCLTdJgxdxiy4P6fE8BxiQAAIwAGYZT1O+b84IgyKj5RfD4MQWAGDDkgLzEgKQaZsCGFCcgGBMm80EMScwTV1XOi6PEXFVgQT+hRUinY-NQjapiKy0wc4Ki8RAYEDBagsAAC9abKEgCqC4hreQSEmVweEpREShnFb0pxDz3ANSapcFqbUOoGvAMAfGkBs05tzXmyAAA9AA-FKwBtwdh3HldsYkZgxBBAgV631ZRIDQuaeJbKchTVKyxEIbl5NNl9oeMqhVZKgjrBuHsLw1odWyHmHUcpeAeWOH8LijolB0DmqSOGBdBhKnNPrTQRtfqdgktHboKNXY3ASu1voH8Gas35sfdm4tLCNFjkXSweAdAhTXsnJ4iNZCY01IebWTNuaX2luLAwCBkxoFGuCOwU5zgtU6pKWUip7qQiEnDYGj0F7wAQOrZATkk5RRAb6Q8qeycZ4lTKhVXcVUUDLxlKBh9haS0EdabIf0KYyNXtjf4-5j9nzvkLix+94Gi1AA

💻 Code

/**
 * Mimicking rxjs to avoid dependency import
 */

type Observable<X> = {
	subscribe(): Observable<X>
};

enum CPEvents {
	CLICK = "click",
	PLAY = "play",
	CANPLAY = "canplay",
	PLAYING = "playing",
	PAUSE = "pause",
	ERROR = "error",
	ENDED = "ended",
	LOADSTART = "loadStart",
	RATECHANGE = "ratechange",
	WAITING = "waiting",
	SEEKING = "seeking",
	SEEKED = "seeked",
	TIMEUPDATE = "timeupdate",
	VOLUMECHANGE = "volumechange",
	DURATIONCHANGE = "durationchange",
	ADDTRACK = "addtrack",
	EMSG = "emsg",
	PLAYBACK_BEGIN_HALTED = "playbackBeginHalted",
	START_TIME_AVAILABLE = "startTimeAvailable",
	CONTENT_STATE_CHANGED = "contentStateChanged",
	AUDIO_PLAY_RIGHT_ACQUIRED = "audioPlayRightAcquired",
	STATS_UPDATE = "statsUpdate",
}

// Payloads have been replaced for the repro-case, but they do not matter right now.
interface CPMappedEvents {
	[CPEvents.EMSG]: unknown; 
	[CPEvents.DURATIONCHANGE]: unknown;
	[CPEvents.VOLUMECHANGE]: unknown;
	[CPEvents.TIMEUPDATE]: unknown;
	[CPEvents.ERROR]: unknown;
	[CPEvents.RATECHANGE]: unknown;
	[CPEvents.ADDTRACK]: unknown;
	[CPEvents.CONTENT_STATE_CHANGED]: unknown;
	[CPEvents.START_TIME_AVAILABLE]: unknown;
	[CPEvents.PLAYBACK_BEGIN_HALTED]: unknown;
	[CPEvents.STATS_UPDATE]: unknown;
	[CPEvents.AUDIO_PLAY_RIGHT_ACQUIRED]: unknown;
	[CPEvents.SEEKING]: unknown;
	[CPEvents.SEEKED]: unknown;
}

type CPUnmappedEvents = {
	[K in Exclude<CPEvents, keyof CPMappedEvents>]: Event;
};

export type CPEventsMap = CPMappedEvents & CPUnmappedEvents;

export type CPObservableEvents = {
	[K in keyof CPEventsMap]: Observable<CPEventsMap[K]>;
};

declare const eventObservables: CPObservableEvents;

🙁 Actual behavior

Intellisense (autocomplete) suggests two different subset of valid values when accessing a mapped object through dotted access and indexed access, but accessing with a dotted access to an unsuggested (available in indexed access and there fore still valid) property seems to be still valid and well-recognized.

🙂 Expected behavior

The suggested values should be the same if there is not a specific indexed signature.

Additional information about the issue

No response

[RyanCavanaugh]

A minimal repro would really be appreciated. Thanks!

[alexandercerutti]

@RyanCavanaugh So a git repo? I thought the playground was enough as the code would be the same.

If so, should I install Typescript@next?

[fatcerberus]

@alexandercerutti I assume Ryan was only looking at what you put under "Code", which isn't a full repro. That's why the issue template says the Playground and Code section should match.

[alexandercerutti]

@fatcerberus The template says:

Please post the relevant code sample here as well.
This code and the Playground code should be the same, do not use separate examples.

We can quickly address your report if:

The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
The incorrectness of the behavior is readily apparent from reading the sample.

Reports are slower to investigate if:

We have to pare too much extraneous code.
We have to clone a large repo and validate that the problem isn't elsewhere.
The sample is confusing or doesn't clearly demonstrate what's wrong.

I literally added what I was thinking it was "relevant", by taking it from the playground. 😄
That's because in the playground I added a lot of comments.

But if "relevant" means "playground code"... what is playground link need for? eheh

Anyway, I'll change the main message to include the whole code (without comments, I guess, even if it does not make very much sense without them...).

[fatcerberus]

This code and the Playground code should be the same, do not use separate examples.

is the relevant bit.

[fatcerberus]

But if "relevant" means "playground code"... what is playground link need for? eheh

Playground is still useful so you can see hover tips, execute the code, etc.

[RyanCavanaugh]

thought the playground was enough as the code would be the same.

The Playground example is definitely a reproduction, but it usually saves us a lot of time if you can make a minimal reproduction that cuts away any extra cruft. This also makes it easier to find duplicates later, etc.

[alexandercerutti]

@RyanCavanaugh thank you. I hope the code I setup is enough. Let me know if I can add anything further.

[PranavSenthilnathan]

I've tried to simplify this and it comes down to this code:

type Foo = {
	["FOO"]: Event;
}

type Bar = {
	[K in "BAR"]: Event;
};

type FooBar1 = {
	[k in keyof (Foo & Bar)]: number
}

type FooBarKeys = keyof (Foo & Bar);
type FooBar2 = {
	[k in FooBarKeys]: number
}

declare const foobar1: FooBar1;
declare const foobar2: FooBar2;

foobar1 // dot completion: BAR
foobar2 // dot completion: BAR, FOO

I think @alexandercerutti's concern is that foobar1 only has BAR as the completion (this is due to how property access completions don't show for index signatures while they do show for mapped type signatures). I think this seems non-intuitive since keyof is behaving differently when used in the mapped type directly vs another place (FooBarKeys for example), but this doesn't seem like a bug.

[alexandercerutti]

@PranavSenthilnathan thank you for giving a look into this.

You are quite right on your semplification, but still I cannot wrap my head around.

I think this seems non-intuitive since keyof is behaving differently when used in the mapped type directly vs another place (FooBarKeys for example)

This is really really a subtle behavior. To me, there is really no difference with FooBar1 and FooBar2.

I honestly would have issues in explaining this to anyone reading my code. Also, that type (FooBarKeys) would be prone to be removed by anyone not knowing the difference between the two examples above.

Probably, as you say, there is no bug here if the keyof behavior is intended. It might, instead, be considered "only" a very bad user experience matter to me.

If keyof behavior is not intended, that's a bug of course.

When I create libraries, I put very much attention on autocompletion values to help developers, even on custom values with module augmentation. This just to tell you how much I care about autocompletion showing the correct values in any case.

Also, what feels very wrong is seeing a non-suggested value being used and see it as valid (like foobar1.FOO).

Is this keyof behavior difference a documented behavior? I never read of it... do you perhaps have any link for future reference?

Thank you.

[PranavSenthilnathan]

I agree with you, since the compiler knows the access of the properties is valid/invalid, we should offer them for completion. I was looking into this more and it seems like the behavior I mentioned above is actually only on the playground (monaco editor). In VSCode, both completions are shown. Going back to your original example, the dot completion will show the same completions as the index completion with one exception. For the enum, it shows the enum instead of the enum member. Let me just share the VSCode screenshot for your original example.

Dot access:

Index access (the scroll bar doesn't show up in the screenshot but it's there):

The monaco issue is something that you can report there. I believe tsserver will return the remaining completions if they pass the includeInsertTextCompletions flag (or includeCompletionsWithInsertText) here. Then their editor can decide whether or not to show it.

For VSCode (and more generally, tsserver), I think the behavior here should be changed to include the enum members because it's possible only a subset of the enum values are valid properties on the object.

Is this a fair summary of your issue @alexandercerutti ?