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?

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.

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.

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. 😊

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.