-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Roadmap
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 engage and 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
- Adopt the new tree widget across the workbench:
- comments
- quick pick.
- 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.
- Improve working with the file explorer
- 🏃 Support to compress/flatten single child directories
- Investigate 'working sets' of files and folders
- Investigate how to safely provide richer customizability in the workbench
- 🏃 Support custom editors.
- Investigate custom Views (based on WebViews).
- Support synchronizing settings and extensions across VS Code installations on different machines.
- Provide filtering and fast keyboard navigation in trees across the workbench.
- Show 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.
- Investigate a combined search result representation
- Continue to incrementally improve presentation and behavior across the board. Examples include:
- 🏃 Harmonize hovers, completion items, completion item details
- Welcome page
- 🏃 Use tabs instead of the terminal dropdown
- Iconography
- Revisit/review the first run experience (e.g. notification reduction)
- 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
- Touch support
- Expand 'inline' experiences
- Inset editing
- Inline errors
- Richer minimap
- Inline values (on by default, see debugging)
- Smarter indent support (e.g. for Python)
- Bring back localization support in the standalone Monaco editor. This support had been suspended when we added support for language packs for VS Code.
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.
- Workspace level edits
- Enable language extensions to participate in workspace edits (rename, move).
- Enable composite undo of workspace edits.
- Investigate previewing workspace edits (e.g. preview the changes of a rename refactoring).
- 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
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.
- Investigate GitLens synergies
- Improve Github PR extension
- Full merge support
- Improve hovering and inline values by leveraging the knowledge about the programming language so that the
Inline Values
feature can be enabled by default - Investigate 'full stack' debugging improvements, combined node (server) and chrome (client) debugging.
- Support data breakpoints
- Continue to invest in documenting debugging recipes for common configurations
- Investigate how VS Code can improve the testing support. Several extensions are already providing testing support, explore what APIs/UIs could be added to improve these testing extensions.
- Investigate into migration to the MSIX installer on Windows.
-
Extension Acquisition
- Revisit how users find and install extensions
- Improve the recommendation system.
- Add support to only activate signed extensions (see next section).
- Support installing an extension without having to reload the workbench. This is our 3rd most upvoted feature request.
-
Extension Management
- Make the consumption of extensions more secure and improve the process for how we handle malicious extensions.
- Show runtime information for an extension (activation state, performance, error logs)
- Investigate customizing extension contributions by the user (context menus, completion providers).
-
Extension Publishing
- Investigate 'welcome' experience for extensions.
- Informing users about new features/releases.
- Investigate into play grounds like the VS Code playground (
Help>Interactive Playground
) for extensions. - 🏃 Collaborate with extension authors to improve their extensions. Examples are: Use Webpack to improve install and activation, minimize dependencies of an extension, ensure
vscode
is only a development dependency. - 🏃 Enable extensions to install additional platform specific components.
- 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:
- 🏃 VS Code Remote SSH
- 🏃 VS Code Remote WSL
- 🏃 VS Code Remote Containers
- 🏃 GitHub Pull Request extension
- 🏃 Azure Account extension
- 🏃 Vue extension
We will continue to maintain the following extensions:
We will investigate into improving the performance of existing popular extensions that make the extension host unresponsive, e.g., Bracket Pair Colorizer, Auto Rename Tag.
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.
- 🏃 Investigate replacing canvas based rendering through WebGL based rendering
- Work with the
xterm.js
community to improve parsing and internal line representations - Adopt
conpty
on Windows - Reflow lines when resizing the terminal
- Migrate from
tslint
toeslint
. Tslint will be deprecated. - Improve the built-in issue reporter, support to paste/attach images.
- Improve Smoke Tests, revisit the current approach on how we implement the automated smoke tests.
- 🏃 Refresh all of our dated overview videos.
- Make it easier for extension authors to find their way around. Improve our API documentation, and integrate samples and documentation more closely.
- 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!
Project Management
- Roadmap
- Iteration Plans
- Development Process
- Issue Tracking
- Build Champion
- Release Process
- Running the Endgame
- Related Projects
Contributing
- How to Contribute
- Submitting Bugs and Suggestions
- Feedback Channels
- Source Code Organization
- Coding Guidelines
- Testing
- Dealing with Test Flakiness
- Contributor License Agreement
- Extension API Guidelines
- Accessibility Guidelines
Documentation