-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Completions from template literal types #59794
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
Open
MichalMarsalek
wants to merge
7
commits into
microsoft:main
Choose a base branch
from
MichalMarsalek:better-completions-for-template-literal-with-placeholder
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
4b9d6f8
init
MichalMarsalek 8c9de42
initial implementation
MichalMarsalek c162be6
add getStringLiteralCompletionFromTemplateLiteralTypeAndTextOfNode
MichalMarsalek 8d4927f
add tests
MichalMarsalek 9a2ce9b
add tests
MichalMarsalek da8c2a9
cleanup
MichalMarsalek 0c89587
fix testcase by retrying with inference if there aren't any string li…
MichalMarsalek File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
There is an existing algorithm for matching strings against template literal types that you can find in
isTypeMatchedByTemplateLiteralType
. Instead of trying to implement a custom one, I'd recommend looking into how you could reuse that one. You can expose some checker functionality on theTypeChecker
using new methods annotated with/** @internal */
.Perhaps you will have to focus on the algorithm in
inferFromLiteralPartsToTemplateLiteral
. It could return a number for the last segment matched successfully instead ofundefined
. Using this number you could look at the text after it and suggest that as autocompletion.Note that this is just a rough idea, I don't know how feasible it will be in practice 😉
It could be nice to use the same algorithm to autocomplete properties coming from index signatures with template literal keys. You don't have to implement this as part of this PR though. One thing at a time 😅
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.
Hmm, this matching works in the escaped string (source code) space, while the checker's works in raw string content space. Shouldn't be the biggest issue though, instead of escaping the type.text, we would need to unescape token.content. Especially for future generalisations, this is probably a good direction to take but this version is so simple, that I didn't feel the need to use the checker.
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.
Also,
inferFromLiteralPartsToTemplateLiteral
starts by first checking that both the starts and the ends of the source and the target are compatible, which is not what we need here. (Ok but that seems to be just for a perf reason? and could be skipped with a flag.)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.
Actually, I don't think that function is very useful for matching of the partial string. I think that this requires a different algorithm by nature.
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.
Could u expand on that? At the very least the rules there could guide u how to handle number interpolations and more
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.
Sure, there are functions like
isValidTypeForTemplateLiteralPlaceholder
that could certainly prove usefule, but I'm not sure the overall algorithm that finds the target text parts in the source type is that reuseable. Andmeant less "I don't know how to do it" and more "I don't know what it should be doing". Like in
what is the completion? I guess nothing? How about
Maybe replacement of
"ab
with"a
?