Shorten error spans for missing key errors reported on object literals

[ssalbdivad]

🔍 Search Terms

object literal, error span, squigglies, highlight, decoration, editor, range

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When defining an object literal with a missing key, e.g. as a function input, highlight only the first line of the object literal as opposed to the entire node.

📃 Motivating Example

Current behavior (one parameter with missing key):

Suggested behavior (one parameter with missing key):

Current behavior (two parameters with missing keys):

Suggested behavior(two parameters with missing keys):

Here's a TS playground link with the original source:

https://tsplay.dev/N9a3qN

💻 Use Cases

This would make errors clearer and less jarring when defining large objects as function inputs.

[RyanCavanaugh]

I like the motivating example here, though it's definitely not the case that an object literal has a meaningfully-defined "start of line".

One implementation issue is that right now errors get an associated node which provides their error span, so we don't have any architectural way to do a span like

const foo = someFunc({
~~~~~~~~~~~~~~~~~~~~

where the span is a partial covering of part of the tree, nor do we have anything that is like "start at the start of the line" to help make the span not just be a single character that might be in the middle of some other punctuation soup. But I think that'd be fixable with some flags on the error object to say "highlighting the entire thing is not necessary".

Would be possibly open to PRs if we could have some better definition of what a better spanning rule is, showing the difficult cases as well as the easier ones. Super-long error spans aren't great but single-character spans can also be very hard to spot, so ensuring that we're getting a net benefit would be needed.

[ssalbdivad]

@RyanCavanaugh That's very helpful thanks for the additional input.

I was talking about this a bit with @Andarist as perhaps you inferred from the parallel #58061.

I had also suggested potentially just right padding the start of an object literal if the contents before the first newline were less than e.g. 4 chars. I realize there might be some nuance to "if the contents before the first newline...", so we'd need to determine the best way to represent something like that that integrates reasonably well with the current error span model. Depending on what these flags might enable, this might be more intuitive visually:

Although perhaps this would be much less straightforward since I assume VSCode's model for decoration assumes a correlation with existing characters. Just thought I'd throw it out there since IMO, given no restrictions, I think it is the most intuitive and makes the best use of visual space to convey the error location.

[RyanCavanaugh]

Yeah, there's currently no way to make an error squiggle appear in the virtual space beyond the end of a line. Error spans are just start/end.