Typescript: Provide option to disable `?.` completions

[DanielRosenwasser]

Was speaking with @mjbvz today who asked if it made sense to disable optional chaining (a.k.a null propagation, safe navigation, elvis) ?. completions since

• .js users in strict mode might not have a compiler.
• Users in general might find it annoying.

I suppose this would be surfaced in Visual Studio or VS Code's completion options.

[fatcerberus]

I don't understand why a user would want to disable this unless they were just disabling dot-completions in general - if I type foo?.| I still want to see the list of properties that the type system says I can use, that doesn't change just because the value might be undefined...

[DanielRosenwasser]

I suppose there's a different concern between

• "I want to immediately know that I have null/undefined when I hit . by seeing no completions." and
• "I want to see the completions, but I don't want ?. and I will know I have an error after the completion occurs."

[mjbvz]

Feedback from the VS Code team members:

1. A few TS users would like an option to disable auto inserting ?. for completions in TS files. It would also be helpful for users that are compiling with older TS versions but that have not switched their VS Code workspace version

2. Some people would also prefer that if you disable ?. insertion, that we still show the suggestions if the value is possibly undefined. We're not entirely in agreement here: I and a few other people feel that completions should not result in errors while other team members said they would find completions that initially result in an error to be a helpful part of their workflow.

For 3.7 specifically, I think we should be conservative and have a setting that disables suggestions that insert ?. when you have just typed a normal .. This would not change anything if you type out ?. and then request suggestions. If the setting is off, we should fall back to the 3.6 behavior of not showing any suggestions.

/cc @RyanCavanaugh

[fatcerberus]

I want to see the completions, but I don't want ?. and I will know I have an error after the completion occurs.

This confused me at first, but I understand now - the completion engine is automatically changing maybeFoo.bar into maybeFoo?.bar. I can definitely see that being a nuisance in some cases. So yeah it would be nice if there's a way to turn that off -- however I wouldn't want it to be at the cost of losing the list of properties after explicitly typing a ?.

[fatcerberus]

Some people would also prefer that if you disable ?. insertion, that we still show the suggestions if the value is possibly undefined.

Yeah, no, I can't agree with this. Not seeing the list of suggestions is an immediate tip-off that the type of the thing I'm accessing isn't what I expected (i.e. it includes an undefined possibility I didn't account for), vs. a red squiggly underline after-the-fact that I might not immediately connect to the actual mistake I made. In my mind the only sensible options are:

1. Offer . completions, automatically adding ?. if needed
2. Don't offer . completions if the object is possibly undefined

IMO there is nothing in between these two options that makes sense.

[Tyriar]

A few TS users would like an option to disable auto inserting ?. for completions in TS files

I typically disable these types of features personally as I prefer to get used to typing them out explicitly (I also disable auto closing brackets, quotes, surround). Remember that using ?. isn't always the right thing to do and if it was always enabled and wasn't the right thing I'd need to undo the completion or go back and remove the ?.

Some people would also prefer that if you disable ?. insertion, that we still show the suggestions if the value is possibly undefined. We're not entirely in agreement here: I and a few other people feel that completions should not result in errors while other people would find completions that result in an error helpful.

I was initially thinking because it would let me "finish a thought" without the need to go back to it later, but changed my mind for the following reasons:

• Since it would complete as an error I could not continue to . into more properties
• It wouldn't even work for JS as it typically doesn't use strict null checks

But anyway, this should be considered a new feature proposal separate to disabling ?.

[RyanCavanaugh]

It seems like there are a lot of varied use cases on this

[mjbvz]

I'm fine revisiting the broader behavior around completions with 3.8 but think it's important for 3.7 that we give users an opt out setting so that editors don't automatically insert ?.. My proposal is to add a setting called includeChainCompletions or similar on completions. If this is not set, we revert to the current TS 3.6 behavior for when triggering completions on potentially null or undefined values

[DanielRosenwasser]

includeOptionalChainCompletions or includeOptionalChainingCompletions seems reasonable

[fatcerberus]

includeOptionalChainCompletions

This suggests that it also disables completions for explicitly typed ?. which based on discussion above doesn’t seem to be the intent?

I’m not sure what a concise name is for “don’t include completions that require changing . to ?.” though...

[DanielRosenwasser]

34552 has it named includeAutomaticOptionalChainCompletions, the intent being that the user wants to disable completions that require automatic conversion to optional chains.

Aside: naming stuff sure is hard.