Our roadmap typically looks out 12-18 months and we establish topics we want to work on. We don't start with our roadmap on a blank sheet. We develop it based on our last roadmap, the findings we made over the course of the last year, and of course what we heard from you in issues, in face-to-face discussions, stack overflow, and twitter.
When we execute on our roadmap, we keep learning and our assessment of some of the topics listed changes. As a result, we may add or drop topics as we go. After around 12 months we come together to develop the next roadmap.
We describe some initiatives as "investigations" or "explorations" which means our goal in the next few months is to better understand the problem and potential solutions before scheduling actual feature work. Once an investigation is done, we will update our plans, either deferring the initiative or committing to it.
As always, we listen to your feedback and adapt our plans if needed.
Legend of annotations:
| Mark | Description |
|---|---|
| bullet | work not started |
| check mark | work completed |
| 🏃 | on-going work |
| 💪 | stretch goal |
| 🔴 | missing link |
Before we go into the details, let's start with our values that guide the development of VS Code. They have pretty much remained the same since the early days and we don't have any intention to change them:
- Out of the box, VS Code is a text editor: lightweight and fast. Users may install extensions that impact the appearance and nature of VS Code.
- Performance trumps functionality.
- Simple, uniform UI and UI interactions.
- Allow for CLI / UI co-existence and interplay whenever possible.
- Although we limit the UI choices extension authors can make, authors can write powerful extensions such as one that turn VS Code into an IDE with bells and whistles.
For 2021/22, we'll particularly focus in the following themes.
- Continue on our journey to be the best editor for anyone who relies on accessibility features
- Introduce support for Profiles
- Introduce Trusted Workspaces, and explore signed and sandboxed extensions
- Enable extension authors to provide great notebook experiences or contribute custom output renderers to existing notebook experiences
- Update the infrastructure of our website; start the process of visual updates
- Support the official launch of GitHub Codespaces.
- Ensure VS Code loads instantly in the web.
- Trusted workspaces: Ensure it's safe to clone a repo and read the source code without any unauthorized code execution.
- Make VS Code more secure by running renderer processes without access to
nodeAPIs. This is also crucial of the longevity of our platform as it brings our application model closer to the pure web model.- Move from
webviewstoiFrames(we'll continue to refer to the custom views and editors as being webview-based)
- Move from
- Remote-SSH
- Support 'Reopen in Container' leveraging Remote-Container support
- Remote-Container
- Assist users in installing
Dockerwhen not yet installed - Support for untrusted remote-containers
- Assist users in installing
- Rethink: "New Untitled File" is a relict from a time when we only supported text files - how much can we do by automatic detection, how much user input do we need
- Continue to incrementally improve presentation and behavior across the board. Examples include:
- Welcome page
- Improve handling opening a file when there are multiple editors available, for example, let the user choose on first open
- Improve custom editors and custom views
- Improve data transfer between webviews and the extension host
- Support a predefined set of webcomponents in webviews
- Provide extensions more control over the sequence and grouping of their settings in the settings editor, e.g., support to group commonly used settings.
- Support private workspace settings
- Expand editor 'inline' experiences
- Inline values (on by default, see debugging)
- Inline type hints (see language section)
- Explore improved debugging of notebook cell execution
- Investigate synergies between the Core git, GHPRI, and GitLens (implementation sharing, plugin extensibility)
- 🏃 Bring GitHub closer into the inner loop across VS Code Core, and the GHPRI and GitLens extensions
- Support browsing and modifying GH repositories without a need to clone the repository or open a codespace
- Assign from overview editor
- Support resolving conversations
- Provide testing support and help the ecosystem to move over.
- Investigate how to persist local terminal sessions across window reloads and application restarts.
- Investigate improved shell/profile selector (see Windows Terminal for inspiration)
- Use tabs instead of the terminal dropdown
- Investigate to "resume" a terminal by deserializing its state rather than replaying raw data events
- Investigate to allow terminals in the editor area
-
Extension Authoring
- Extend our development tooling:
- Support for web worker extensions
- Revisit the format of our extension author community call
- Extend our development tooling:
-
Extension Publishing (See Security)
- Support for platform specific flavors of extensions.
- Add support for verified publishers.
- Add support for insider/pre-release extensions
- Inline type hints
- Provide an integrated live preview.
- Make VS Code available in the Windows Store.
- Invest into a unified, improved and fast file watching
- 🏃 Improve our GitHub issue bots, examples:
- reject invalid incoming issues automatically
- detect issues of limited use that 'need more information' automatically
- Explore improving the build time by using esbuild (requires AMD support) - ensure we don't lose our ability to use with the latest TS RC
These are examples of some of the work we will be focusing on in the next 12-18 months. We continuously tune the plan based on feedback and we will provide more detail in each of our monthly iteration plans. We will develop our next roadmap in around 12 months from now. Please follow along and let us know what you think!