Setting to hide inlay hints for implicitly-typed variables that are set to literals

[seansfkelley]

Suggestion

🔍 Search Terms

• inlay hints
• implicit variable

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Change the typescript.inlayHints.variableTypes.enabled setting from a boolean to a enumeration, with options:

• none
• non-literals
• all

It may make sense to apply this same treatment to typescript.inlayHints.propertyDeclarationTypes.enabled as well.

📃 Motivating Example

Here is a screenshot of the snippet in my codebase that was the direct inspiration for this request:

The inlay hints are, to me, pretty noisy here.

1. It's obvious what the inferred type of the string literal and object literal will be. The function literal as well, though if I were to remove the type annotations I would be relying on other inlay hints to help me there.
2. The hints for the object literal and function literal are almost useless, even if I wanted to be told the type. It does not take a particularly large object or complex function definition to hit the ellipsis limit for unnamed/unaliased object/function types.

However, I don't want to disable it for all implicitly-typed variables. This inlay hint from later in the same file is very non-obvious because it's behind a wordy function call:

💻 Use Cases

n/a? I think the motivating example section covers this.

[MartinJohns]

This sounds related: #45295

[seansfkelley]

This might be tangential, but as a user it feels related, so I'll add it here anyway:

Maybe lump constructors in with "literals" so they don't appear when non-literals is set?

But of course, this is only redundant and not useful because the type parameters are explicitly specified. If they weren't, I'd probably like to know that the inferred type would be, e.g., Set<unknown>. 🤔