# LSIF ([[Code Indexing]]) The Language Server Index Format (LSIF) is a standard format for language servers or standalone tools to emit their knowledge about a code workspace. This persisted information can later be used to answer Language Server Protocol (LSP) requests for the same workspace without running a language server [Source 1](https://lsif.dev/). LSIF builds on LSP and uses the same data types as defined in LSP. It models the data returned from language server requests. LSIF doesn't contain any program symbol information nor does it define any symbol semantics. The LSIF therefore doesn't define a symbol database, which is consistent with the LSP approach [Source 0](https://code.visualstudio.com/blogs/2019/02/19/lsif). LSIF uses graphs to emit this information. In the graph, an LSP request is represented using an edge. Documents, ranges, or request results (for example, the hover) are represented using vertices. This format has the following benefits: - For a given code range, there can be different results. For a given identifier range, a user is interested in the hover value, the location of the definition, or to Find All References. LSIF therefore links these results with the range. - Extending the format with additional request types or results can easily be done by adding new edge or vertex kinds. - It is possible to emit data as soon as it is available. This enables streaming rather than having to store large amounts of data in memory. For example, emitting data for a document should be done for each file as the parsing progresses [Source 0](https://code.visualstudio.com/blogs/2019/02/19/lsif). Here is an example of how LSIF works with a hover request: ```javascript // a vertex representing the document { id: 1, type: "vertex", label: "document", uri: "file:///Users/username/sample.ts", languageId: "typescript" } // a vertex representing the range for the identifier bar { id: 4, type: "vertex", label: "range", start: { line: 0, character: 9}, end: { line: 0, character: 12 } } // an edge saying that the document with id 1 contains the range with id 4 { id: 5, type: "edge", label: "contains", outV: 1, inV: 4} // a vertex representing the actual hover result { id: 6, type: "vertex", label: "hoverResult", result: { contents: [ { language: "typescript", value: "function bar(): void" } ] } } // an edge linking the hover result to the range. { id: 7, type: "edge", label: "textDocument/hover", outV: 4, inV: 6 } ``` In this example, the LSIF graph data is represented as vertices and edges. The vertices represent the document, the range for the identifier, and the actual hover result. The edges link the document to the range and the hover result to the range [Source 0](https://code.visualstudio.com/blogs/2019/02/19/lsif). LSIF is useful for many repositories where the only two build environments that understand the code well enough to provide code intelligence are your editor and CI. With LSIF, a build step in CI can dump information about the code to a file which can be transported anywhere. For example, code browsers only need that LSIF dump in order to provide hover tooltips, jump-to-definition, and find-references [Source 1](https://lsif.dev/).