As 2018 has come to an end, now is the time to look towards the future. We typically look out 6 to 12 months and establish topics we want to work on.
As we go we learn and our assessment of some of the topics listed changes. Thus, we may add or drop topics as we go.
We describe some initiatives as "investigations" 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 plan, either deferring the initiative or committing to it.
As always, we will 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 |
Our roadmap covers the following themes:
- Become the best editor out there for anyone who relies on accessibility features.
- performance, scalability, serviceability, security
- tackle some of the most wanted user features
- polishing and a constant slow trickle of design refreshments
- incrementally improve already existing features
- responsibly enable extensions that have broader extensibility requirements
- 🏃 Make VS Code an outstandingly accessible developer tool. We'll work with our community to get input and guidance, and we need you to keep us honest.
- 🏃 Keep start-up times within a predictable and suitable range for users across all platforms and improve the overall performance for large workspace:
- Load less code on start-up and investigate improving the workbench restoration time by expanding on the rapid render approach.
- 🏃 Implement a new tree widget that scales better and adopt it across the workbench (explorer, search, settings, outline, debugger).
- Improve serviceability
- 🏃 Make it easy to identify extensions that negatively impact the overall performance of VS Code.
- Workbench layout
- Support for detachable workbench parts is our most upvoted feature request which due to architectural issues is challenging to implement. We will explore how we can work around this limitation. This investigation will focus on detaching terminals (2nd most upvoted feature request) and editors.
- 🏃 Enable a more flexible panel/sidebar layout.
- Provide filtering and fast keyboard navigation in trees across the workbench.
- Investigate showing search results not only in the side bar or a panel, but also in an editor. This allows us to show additional context information for each match.
- Improve working with the file explorer in large workspaces
- Investigate 'working sets' of files and folders
- 🏃 Explore flatting folder hierarchies in the explorer
- Investigate how to safely provide richer customizability in the workbench
- Investigate custom viewlets and panels.
- Investigate custom editors comparable to the Welcome page.
- 🏃 Investigate
node-free renderer processes to be ready for electron 5.0
- Continue to incrementally improve presentation and behavior across the board. Examples include:
- 🏃 Harmonize hovers, completion items, completion item details
- 🏃 Iconography
- Welcome page
- 🏃 Use tabs instead of the terminal dropdown
- Explore how to integrate fluent design on Windows
- Investigate isolating the editor from misbehaving grammars.
- Investigate support for semantic coloring
- Investigate how to simplify the maintenance of textmate grammars
- Bring back localization support in the standalone Monaco editor. This support had been suspended when we added support for language packs for VS Code.
- 🏃 Improve the WSL support.
- Investigate how we can enable extensions to leverage tools available in WSL.
- Investigate which other scenarios are being enabled by the changes needed for WSL
- 🏃 Improve 'Expand Selection' to better adhere to the semantics of programming languages.
- Improve support for navigating and presenting complex error descriptions such as those generated by TypeScript for React or Vue.
- 🏃 Enable programming language extensions to provide support for call hierarchies.
- Enable programming language extensions to provide support for type hierarchies.
We will continue to collaborate deeply with the TypeScript team to deliver the richest code editing, navigation, and understanding experiences for both TypeScript and JavaScript. see also the TypeScript roadmap.
- Support data breakpoints
- Improve hovering and inline values by leveraging the knowlegde about the programming language
- 🏃 Continue to invest in documenting debugging recipes for common configurations
- Support installing an extension without having to reload the workbench. This is our 3rd most upvoted feature request.
- Integrate the runtime information shown by
Developer: Show Running Extensionsinto the existing extension UI such as Extension viewlet and Extension editor. - Improve the extension recommendation system.
- Make the consumption of extensions more secure and improve the process for how we handle malicious extensions.
- The existing process worked as the event-stream issue showed, but we also learned that there is room for improvements: support to uninstall a particular version of an extension, provide access to information about why an extension is being uninstalled, automatically re-install an extension when the issue is fixed.
- Add support to only activate signed extensions (see next section).
- Collaborate with extension authors to improve their extensions. Examples are: Use Webpack to improve install and activation, minimize dependencies of an extension, ensure
vscodeis only a development dependency. - 🏃 Enable extensions to install additional platform specific components at extension installation time.
- Support publishing of signed extensions.
- Add support for verified publishers.
Our teams contributes to a number of extensions that are available in the market place.
Our main focus will be on the following extensions:
We will continue to maintain the following extensions:
VS Code is made possible through a wide range of technologies. Below are examples of technologies in which we are particularly active.
- 🏃 Continue to refine and improve the Language Server Protocol with support from the community.
- Define a Language Server Index Format (LSIF, pronounce like "else if") that enables a language server to persist their language intelligence, so that it can be subsequently used to answer LSP requests at-scale (for example, hover and go to definition).
- 🏃 Continue to refine and improve the Debug Adapter Protocol with support from the community.
- 🏃 Expose more UI for DAP features that are currently not surfaced in the VS Code debugging UI. This includes moving the loaded scripts UI into the core.
- Work with the
xterm.jscommunity to improve parsing and internal line representations - Adopt
conptyon Windows - Reflow lines when resizing the terminal
- Investigate replacing canvas based rendering through WebGL based rendering
- Make it easier for extension authors to find their way around. Improve our API documentation, and integrate samples and documentation more closely.
- 🏃 Refresh all of our dated overview videos.
- We'll continue our work on our GitHub bots that enable members of our community give us a hand triaging and resolving issues.
These are examples of some of the work we will be focusing on in the next 6 to 12 months. We continuously tune the plan based on feedback and we will provide more detail in each of our monthly iteration plans. Please follow along and let us know what you think!