Repository navigation
No string completions in type arguments where constrained to string literal union #52898
Description
A friend of mine recently tried using JSX generics and it seems like the fix in #34958 did not work for them.
Here is an oversimplified code snippet that replicates the issue. We've tried this in two different machines and neither worked:
import * as React from "react"
type Variations = "hello" | "baaaaa" | "click"
const MyGeneric = <T extends Variations>({ }) => {
return <div></div>
}
const Issue = () => {
return <MyGeneric<"ctrl+space should bring up suggestions here">></MyGeneric>
}
Originally posted by Adonis Kakoulidis (@varemenos) in #34110 (comment)
Reacted by Vitaly, Adonis Kakoulidis, seb, sadan and Jayden Carey
Activity
Andarist commentedon Feb 21, 2023
For the record - this isn't exclusive to JSX. It doesn't work with regular call expressions either (TS playground):
[-]No string completions in JSX element type arguments[/-][+]No string completions in type arguments where constrained to string literal union[/+]Andarist commentedon Feb 22, 2023
And it's not even about string completions:
I didn't do further research right now to confirm this but I'm under impression that completions just don't work in type arguments.
andrewbranch commentedon Feb 22, 2023
When I was looking for duplicates, I saw #43526, so I assumed that some support is implemented and there are just big gaps.
kronodeus commentedon Nov 7, 2023
Here is an even more simplified example that demonstrates that functions get no completions at all for type arguments while type references do:
I can't think of a reason why completion requests for type arguments can't be routed down the same code path for functions as they are for type references.
mkantor commentedon May 23, 2025
I looked into this briefly while working on #61758. I noticed that having the cursor within a string literal type argument of an expression is a "known invalid completion location" according to
getCompletionDataincompletions.ts. A fix for this issue would probably have to address that before anything else.mkantor commentedon May 23, 2025
Mateusz Burzyński (@Andarist)
There's a constellation of related issues:
test<{ /*3*/ }>()example.tsserverfor property values in generic type arguments #56299 is a separate issue which I haven't looked deeply at yet. Even if #61758 lands, yourtest<{ type: /*1*/ }>()example still won't work because of this. The same thing happens for type arguments of type constructors (Completion list for type literals in type arguments #43526 didn't attempt to address this either).test<{ type: '/*2*/' }>()example are all within string literal types, which it turns out is explicitly considered invalid as per my previous comment and probably needs dedicated work to fix separately from the other issues.