This is used as a part of restarting the language service.
Gets global diagnostics related to the program configuration and compiler options.
Gets the extended details for a completion entry retrieved from getCompletionsAtPosition.
The path to the file
A zero based index of the character where you want the entries
The name from an existing completion which came from getCompletionsAtPosition
How should code samples in the completions be formatted, can be undefined for backwards compatibility
Source code for the current file, can be undefined for backwards compatibility
User settings, can be undefined for backwards compatibility
Gets completion entries at a particular position in a file.
The path to the file
A zero-based index of the character where you want the entries
An object describing how the request was triggered and what kinds of code actions can be returned with the completions.
Gets semantic highlights information for a particular file. Has two formats, an older version used by VS and a format used by VS Code.
The path to the file
Which format to use, defaults to "original"
a number array encoded as triples of [start, length, ClassificationType, ...].
Encoded as triples of [start, length, ClassificationType].
This will return a defined result if the position is after the > of the opening tag, or somewhere in the text, of a JSXElement with no closing tag.
Editors should call this after > is typed.
Gets semantic information about the identifier at a particular position in a file. Quick info is what you typically see when you hover in an editor.
The path to the file
A zero-based index of the character where you want the quick info
Gets warnings or errors indicating type system issues in a given file. Requesting semantic diagnostics may start up the type system and run deferred work, so the first call may take longer than subsequent calls.
Unlike the other get*Diagnostics functions, these diagnostics can potentially not include a reference to a source file. Specifically, the first time this is called, it will return global diagnostics with no associated location.
To contrast the differences between semantic and syntactic diagnostics, consider the sentence: "The sun is green." is syntactically correct; those are real English words with correct sentence structure. However, it is semantically invalid, because it is not true.
A path to the file you want semantic diagnostics for
Gets suggestion diagnostics for a specific file. These diagnostics tend to proactively suggest refactors, as opposed to diagnostics that indicate potentially incorrect runtime behavior.
A path to the file you want semantic diagnostics for
Gets errors indicating invalid syntax in a file.
In English, "this cdeo have, erorrs" is syntactically invalid because it has typos,
grammatical errors, and misplaced punctuation. Likewise, examples of syntax
errors in TypeScript are missing parentheses in an if statement, mismatched
curly braces, and using a reserved keyword as a variable name.
These diagnostics are inexpensive to compute and don't require knowledge of
other files. Note that a non-empty result increases the likelihood of false positives
from getSemanticDiagnostics.
While these represent the majority of syntax-related diagnostics, there are some
that require the type system, which will be present in getSemanticDiagnostics.
A path to the file you want syntactic diagnostics for
Generated using TypeDoc
fileNamewill be ignored