-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Completion list for type literals in type arguments #43526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
This looks like it's going in the right direction, but I haven't looked at this part of the codebase in a bit. |
@typescript-bot pack this |
Heya @andrewbranch, I've started to run the tarball bundle task on this PR at 7c0366e. You can monitor the build here. |
Hey @andrewbranch, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running |
Annoying that the playground build didn't work. @typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 7c0366e. You can monitor the build here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the code, it looks very clean and it seems like it does exactly what I'd expect - actually, it does more than that, specifically accounting for intersections which I hadn't thought of!
I guess one thing I do wonder about is how this interacts with symbols, and non-identifier keys (e.g. keys with spaces, keys with numbers at the beginning, fully numeric keys). Those are very niche scenarios so I won't exactly block on that, but completions shouldn't feel intrusive there.
We should also consider these to be new identifier definition locations (e.g. you can specify more than what's there without the editor getting in your way).
(see #42595 (comment) for what I mean on that last point)
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple nits, but looks great overall.
src/services/completions.ts
Outdated
return undefined; | ||
} | ||
|
||
function tryGetTypeArgumentSubType(node: Node, checker: TypeChecker): Type | undefined { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name is a little confusing—it looks like it’s getting the constraint of a type argument, and then optionally drilling into a property of that constraint type, based on the syntax location of the cursor. I was confused about why we’d want to get a subtype of a type argument when its constraint is necessarily a supertype of it. Maybe getConstraintOfTypeArgumentProperty
or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed the naming isn't correct, and I was looking for something like what you suggested. Nice!
src/services/completions.ts
Outdated
const objectTypeLiteralCompletions = getObjectTypeLiteralInTypeArgumentCompletions(sourceFile, position, contextToken, typeChecker, compilerOptions, log, preferences); | ||
if (objectTypeLiteralCompletions) { | ||
return objectTypeLiteralCompletions; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of putting this here, did you look at adding to getCompletionData
-> tryGetGlobalSymbols
? It feels similar to tryGetObjectLikeCompletionSymbols()
and tryGetClassLikeCompletionSymbols()
so I expected it to be another case in that big chain of logical ORs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did look into it initially, but wasn't sure whether it would be the best place to put it. However, I tried moving the code there, and it still works as expected, so I think it should be fine :-)
- Move main logic onto tryGetGlobalSymbols function
|
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 81a48fe. You can monitor the build here. |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks! @DanielRosenwasser, any other edge cases you want to check?
This PR aims to provide some type literal completion for type arguments, as suggested in #33302. It takes in mind intersection and union types, as well as nested type literals.