Extending Visual Studio Code
If you are interested in extending VS Code, you are in the right place. Here we present an outline of the VS Code extensibility documentation and how to quickly build your first VS Code extension. If you're curious about our design approach to extensibility for VS Code, you can read about it here.
All VS Code extensions share a common model of contribution (registration), activation (loading) and access to the VS Code extensibility API. There are however two special flavors of VS Code extensions, language servers and debuggers, which have their own additional protocols and are covered in their own sections of the documentation.
- Extensions - the base building block
- Language Servers - for high cost IO or CPU intensive tasks
- Debuggers - wire up an external debugger
All extensions when activated run in our shared extension host process. This separate process for extensions ensures that VS Code remains responsive through-out.
Extensions include support for:
- Activation - load an extension when a specific file type is detected, when a specific file exists, or when a command is selected via the Command Palette or a key combination
- Editor - work with the editor's content - read and manipulate text, leverage selection(s)
- Workspace - access open editors, the status bar, information messages and more
- Eventing - connect to the editor life-cycle events such as: open, close, change, and more
- Evolved editing - create providers for rich language support including IntelliSense, Peek, Hover, Diagnostics and much, much more
We have two end-to-end walkthroughs to get you going on extension basics:
- Hello World - generate a basic extension, understand an extension's folder structure, the extension manifest, learn how activation works, run and debug your extension and install it locally.
- Word Count - activate based on a specific file type, update the status bar, respond to changes in the text editor, and dispose your extension when moving off the file.
Also helpful is Extensibility Principles and Patterns which describes the shared programming patterns used throughout the extensibility API.
Language servers let you create a dedicated process for your extension. This is a useful design choice for your extension when your extension runs high cost CPU or IO intensive tasks which could slow other extensions. This is common for tasks that work across all files in a workspace e.g. linters or static analysis suites.
Find out more about language servers.
VS Code implements a generic debugger UI and relies on debugger extensions and so called "debug adapters" to connect the debug UI to a real debugger or runtime. A debug adapter is a dedicated process that communicates with VS Code through the VS Code Debug Protocol and can be implemented in any language.
Find out more about creating debugger extensions.
The easiest way to see VS Code extensions in action is via the Extension Marketplace. You can browse for useful extensions, install them to try them out and get an idea how you might extend VS Code for your own development scenarios.
Language Extension Guidelines
To help you decide what language features you'd like to support with your extension, we have a Language Extension Guidelines topic which shows the various language features available in VS Code (for example, code suggestions and actions, formatting, renaming) and how to implement them through either the language server protocol or by using the extensibility API directly from your extension.
Writing an Extension
Install and Share
We also have great support for writing and running tests for your extension. You can easily create integration tests which call the VS Code APIs and test your code in a running VS Code instance.