-
Notifications
You must be signed in to change notification settings - Fork 54
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
feat: extend typescript help signatures with mongodb items VSCODE-403 #509
base: main
Are you sure you want to change the base?
Conversation
…escript-help-signatures
src/language/tsLanguageService.ts
Outdated
// Return a new instance of the language service. | ||
getLanguageService(jsDocument: TextDocument): ts.LanguageService { | ||
currentTextDocument = jsDocument; | ||
return jsLanguageService; | ||
}, |
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.
The comment above this function and its name are a bit misleading – the function always returns the same instance, not a new one. Would it make more sense to either a) create a new language service instance each time or b) split this function into two functions, getLanguageService(): ts.LanguageService
and setCurrentTextDocument(jsDocument: TextDocument): void
?
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.
The getLanguageService
function is a part of ts.LanguageServiceHost type, which we can not extend with setCurrentTextDocument
. Rephrased the comment to reduce confusion.
src/language/tsLanguageService.ts
Outdated
}; | ||
|
||
// Create the language service files. | ||
const jsLanguageService = ts.createLanguageService(host); |
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.
[Question only:] Correct me if I’m wrong, but the general structure here is that host
serves as our way to connect the TS logic to our VSCode documents, but other than that, the LanguageService
instance is unaware of the fact that it’s running against a VSCode environment/as part of a VSCode extension. Is that right? Could we potentially use this, say, inside of mongosh to provide autocompletions there?
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.
Yes. I just tried to use it in tsLanguageService for completions:
doComplete(
document: TextDocument,
position: Position
): CompletionItem[] {
const jsDocument = TextDocument.create(document.uri, 'javascript', document.version, document.getText());
const jsLanguageService = this._host.getLanguageService(jsDocument);
const offset = jsDocument.offsetAt(position);
const jsCompletion = jsLanguageService.getCompletionsAtPosition(
jsDocument.uri,
offset,
{ includeExternalModuleExports: false, includeInsertTextCompletions: false }
);
...
}
and in global.d.ts:
declare global {
enum Stages {
match = '$match',
}
let db: {
getCollection(coll: string): {
find(query?: Document, projection?: Document, options?: FindOptions): Promise<FindCursor>;
aggregate(pipeline: [{ [key in Stages]: Document }], options: Document & {
explain?: never;
}): Promise<AggregationCursor>;
aggregate(pipeline: [{ [key in Stages]: Document }], options: Document & {
explain: ExplainVerbosityLike;
}): Promise<Document>;
aggregate(...stages: [{ [key in Stages]: Document }]): Promise<AggregationCursor>;
};
};
}
And this will give us completions.
So as your comment below states the next step here is to figure out how to create a .d.ts file
that would include everything we need, so we could reuse it across all products.
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.
But all of this does not solve the Int8Array.find
problem anyway :) it continues to appear even knowing the context.
src/types/global.d.ts
Outdated
|
||
declare global { | ||
let use: (dbName: string) => void; | ||
} |
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’m guessing the next step here is to figure out how to create a .d.ts file for mongosh environments? Probably not something for this PR, though 🙂
…escript-help-signatures # Conflicts: # package-lock.json # package.json # src/language/server.ts # src/language/visitor.ts
…escript-help-signatures # Conflicts: # src/language/server.ts
Description
The JS contextual signature help for
find
thinks that anyfind
keyword is theArray.find()
method. This is confusing for users of the extension, because MongoDB has its own usage and syntax the find method.VSCode does not allow extensions to change the results of other extensions, therefor to overcome this obstacle we use the TypeScript Language Service API to extend default JavaScript Method Signatures in playgrounds.
If the cursor is positioned in the query node we show the query method help:
And similarly for the aggregate method, we show the aggregate method help:
If the current node is neither
find
noraggregation
, we return the TypeScript language server help signatures.Checklist
Motivation and Context
Types of changes