Fix JSX attribute completion for union types containing string-like t…

[IAmArthurAdams]

…ypes

Fixes #62237

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[IAmArthurAdams]

@microsoft-github-policy-service agree

[jakebailey]

I'm confused by "has non object types"; is this not actually reporting whether or not some member is string or undefined or null?

Can you go into detail somewhere (PR description, comment, something) about what specific case the repro is hitting and what special casing is required?

[IAmArthurAdams]

Thank you for the feedback!
I’ve renamed hasNonObjectTypes to hasPrimitiveTypes and updated the comment to better reflect what the check is actually doing.

The logic specifically checks whether the union contains both string-like types and primitive types (string, undefined, null). This distinction matters in cases like Preact’s Signalish<string | undefined> (which expands to string | undefined | SignalLike<string | undefined>):

Without ensuring a string-like type is present, TypeScript might apply this rule to unions like null | undefined, where quotes wouldn’t make sense. With this special-casing, we only switch to quoted completions ("$1") when the union actually includes string primitives.

[jakebailey]

But number is primitive too? (We have a definition of Primitive in this codebase and it is different, so terminology is important.)

I'm just finding this PR strange because the effect is "any union that contains a string and undefined or null gets completions with quotes"). That meaning is obscured in your code because to get there the code first checks if all elements are strings/undefined, which the second branch will of course match as well.

Basically, the code here looks complicated, but is effectively equivalent to swapping every to some + only checking TypeFlags.String in the original code, which indeed passes the same tests.

And that's the core problem; Signalish<string | undefined> is string | undefined | SignalLike<string>, and Signalike<string> is an object, and so our old code rejected it because you might want to write a non-string. So this isn't a bugfix, this is a design change we'd need to weigh.

[IAmArthurAdams]

Thanks for the thorough feedback!

I agree the term “Primitive” doesn’t fit well with the repo’s existing definitions, so I could rename that variable to something clearer like hasStringishOrNullableTypes to avoid confusion.

I understand that this change is more of a design choice than a bugfix. For union types like Signalish<string | undefined>, users generally expect quoted string completions rather than brace completions, even though the union includes object-like members. The original code’s strict “all types must be string-like or undefined” check prevented that and led to a less intuitive experience.

While the new logic looks similar to swapping every for some, the goal was to cover these practical cases where quoted completions make more sense despite object members being present.

If this behavior shift feels too broad for this PR, I’m happy to revise or work on a more thorough approach based on your guidance. I’m also fine keeping this PR open whilst it is determined if this change is needed at all. 😊

[jakebailey]

If anything, I would prefer if the PR were just changed to some + checking just TypeFlags.StringLike, since that's the actual change and what we'd accept if we wanted to change this.

And no offense, but I can tell that this is all LLM generated code and comment replies; the explanation ("While the new logic looks similar to swapping every for some, the goal was to cover these practical cases where quoted completions make more sense despite object members being present.") doesn't make much sense in context of what I said. It's a bit distracting.

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate