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.
Over the course of the last years we made significant progress on our original roadmap. So, not surprisingly one major topic for this year is to evolve this roadmap to guide us for the next 2-3 years. We will continue our push to become the leader in accessibility, and bring features to you that you're asking for. The elephant in the room is clearly the support for AI. We will continue to focus on exploring and understanding how AI changes how we all develop. Just like with Remote, parts of this work will be in the open, and parts will be closed source. We will continue to develop, improve, and ship the GitHub Copilot Chat extension.
- 🏃 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.
- Move off our custom IME story and use
ContentEditableto improve text segmentation for RTL and CJK.
- Reduce the size of our downloads
- Investigate more place holders with lazy downloads such as the WSL stubs (extend to core concepts)
- 🏃 Keep startup times within a predictable and suitable range for users across all platforms.
- Improve VS Code performance in large workspaces
- Investigate 'working sets' of files and folders in the file explorer
- Improve Open File / Quick Pick performance
- 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
- Add support to allow users to enforce that only select signed extensions are activated / or can be installed.
- 🏃 Ensure all extension code can be signed (needs platform specific extensions)
- Explore sandboxing of extensions in both local and remote scenarios
- 🏃 Simplify to move from a local folder to a container to a codespace or the other way around
- Remote-SSH
- Provide web access to Remote-SSH boxes through a tunnel service
- Prevent server installation on micro-instances
- Support 'Reopen in Container' leveraging Remote-Container support
- Remote-Container
- Simplify creating a custom dev container configuration, e.g., 'a la cart consumption of the features in the universal image'
- Assist users in installing
Dockerwhen not yet installed - Support for untrusted remote-containers
- Make the VS Code Server available for download; bundled web UI to support older OS versions that the desktop client no longer supports
- See also Support browsing and modifying GH repositories in the SCM section.
- Finalize extensibility story for Copilot Chat through Agents
- Improve our built-in agents
@workspaceand@vscode - Refine the usage model for Inline Chat
- 🏃 Review the default values for all settings we ship out-of-the-box
- 🏃 Investigate how users can express what they want to use VS Code for after they installed it and provide help with setting up their environment: runtime, extensions, settings.
- Make it easier for new users to discover the command palette; explore slack/team-like placement
- 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
- Refresh the themes we ship out of the box
- Continue to incrementally improve presentation and behavior across the board. Examples include:
- Welcome page
- 🏃 Rethink gutters (interactions, number of gutters, codicon support)
- Command palette touch-ups
- 🏃 Revisit/review the first run experience for VS Code as well as newly installed extensions. For example, we want to reduce the number of notifications and allow extensions to integrate their welcome screens into the workbench's welcome page that are shown.
- 🏃 Improved touch and mobile support.
- 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.
- Support a more flexible workbench layout such as allow sidebars on the left and the right. For example, you could have your outline on the right and the file explorer on the left.
- Support to configure the workbench (also see microsoft/vscode#115641)
- Workbench font and font size
- Workbench display density (small versus large buttons, compact activity bar)
- Broaden support to customize the UI, e.g. configure available actions in the menu bar, context menus, toolbars. Investigate Bartender like support.
- Introduce profiles describing appearance (and behavior) or the workbench (and extensions); related to Sets of Settings, maybe it's the same, we don't know yet; Examples: Text editor profile, IDE profile, Student profile
- Explore to enable users (or the workbench on the user's behalf) to manage notifications
- Improve handling opening a file when there are multiple editors available, for example, let the user choose on first open
- Clean-out or finalize APIs that have been in proposed mode for quite some time such as Search
- Improve custom editors and custom views
- Improve data transfer between webviews and the extension host
- Support web-workers in webviews
- Support a predefined set of webcomponents in webviews
- Our API provides access to open text editor, but not notebooks, or custom editors. Extension authors rely on less than optimal workarounds.
- Enrich tree views to lower the need to implement a custom webview-based view (model-based search/filtering, inline editing, help text, large buttons, drag&drop, checkboxes)
- 🏃 Investigate an improved quick pick. Examples: multiline input, mix of checked/uncheckable items, disabled items, inline actions
- 🏃 Provide high-fidelity support for additional settings types, such as colors.
- Provide a simplified theme customization support ("define 6 base colors")
- Support language overwrites in the high fidelity settings editor
- 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 synching of different 'settings profiles' (machines at work, my home machines)
- Support private workspace settings
- Support Sets of Settings/extensions users can switch between (e.g. note taking, java dev, react app); related to Workspace Profiles (maybe it's the same, we don't know yet)
- Option to show search results in a hierarchical way
- Expand editor 'inline' experiences
- Inline values (on by default, see debugging)
- Inline type hints (see language section)
- Spell-checking as a driver for improving how a user interacts with diagnostics. Spelling errors are frequent and frequently on the same line. Going through the quick-fix is not sufficiently fluent. Outlook, for example, uses a single-click.
- 🏃 Achieve feature parity with regular text editors: minimap, scrollbar markers, find across inputs and output
- 🏃 Public notebook API and allow dedicated notebook extensions in the VS Code marketplace; extension recommendations
- Extend language servers to natively support notebooks
- Explore improved debugging of notebook cell execution
- 🏃 See "Markdown" section for what may apply to markdown cells
- 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
- Filter comments in comment view by resolved status
-
@and#completions everywhere including comments
- Improve the diff experience
- Actions for copying changes back and forth in the diff editor gutter
- Full 3-way compare and merge support
- Explore showing the changes across all changed files in a single diff editor
- Collapse unchanged lines
- Investigate support for showing a local history of a file and folder and combine that with the git history
- Investigate combining local history with other events such as successful test runs or refactorings
- Leverage language services to improve debug experience. For example, improve hovering and inline values by leveraging the knowledge about the programming language so that the
Inline Valuesfeature can be enabled by default - Expose more UI for DAP features that are currently not surfaced in the VS Code debugging UI. This includes to support Memory and Disassembly views.
- Explore integration of a html/css inspector. This gap limits our appeal for browser debugging. Align with existing extensions like the edge extension.
- Make JS profiling more discoverable and approachable (provide help in reading performance profiles)
- Investigate support expressions in the JS Debug Console
- Allow running/debugging a single TS file without any setup
- Improve variable inspection when running minified code
- 🏃 Continue to refine and improve the Debug Adapter Protocol with support from the community.
- 🏃 Ensure Testing support scales for mono repos
- Explore code coverage support
- 🏃 Support to navigate from a function to its tests and vice versa
- 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
- 🏃 Provide ongoing improvements to
xterm.jsfor performance, stability, and maintainability - Explore intellisense-inspired CLI help support in the terminal
-
Extension Acquisition
- 🏃 Make it easier for users to pick and choose which functionality they want from extensions.
-
Extension Management
- 🏃 Show runtime information for an extension (activation state, performance, error logs)
-
Extension Authoring
- 🏃 Provide clear guidance to extension authors for how to structure their functionality so that their users can get as little or as much functionality as they want. For example, ensure text editor lovers can get Python language support without too much overhead.
- Provide an integrated 'Welcome' experience for extensions.
- 🏃 Investigate how to effectively inform users about new features provided by an extension update.
- Extend our development tooling:
- Support for web worker extensions
- Improve testing (unit testing and Playwright)
- 🏃 Integration of non-JavaScript code via WASM; investigate whether it would make sense to have a fully mirrored VS Code API, for example, in Rust so that an extension can fully be built in Rust
- 🏃 Make it easier for language extensions to run in a web-worker
- Extend our extension guidelines to not only cover UX, but also performance
- Allow extension authors to integrate GH Sponsor information
- Revisit the format of our extension author community call
-
Extension Publishing (See Security)
- Support for platform specific flavors of extensions.
- 🏃 Support publishing of signed extensions.
- Add support for verified publishers.
- Add support for insider/pre-release extensions
- 🏃 Improve the built-in issue reporter
- Support to paste/attach images
- 🏃 Allow extensions to contribute data to the reported issues (templates, extension logs)
- Investigate hand-off/continuity service: When opening the same folder in different VS Code installs we hand over all untitled files, uncommitted or untracked changes, and some UI state.
We will continue to collaborate deeply with TypeScript. See also the TypeScript roadmap.
- 🏃 Explore with additional refactorings provide high value to developers, e.g., 'change signature'
- Inline type hints
- Explore supporting multiple files/libraries in the Web Worker based language service
We have a dedicated Python Roadmap.
- Provide an integrated live preview.
- Provide a markdown language server
- 🏃 Improve support for images (paste images, preview images on hover, etc.)
- Investigate integration of a spell-checking service (such as MS Editor)
- In-place toolbar for formatting markdown ("code actions on steroids")
- 🏃 Investigate first-class WASM support (authoring, debugging, ...)
- 🏃 Continue to refine and improve the Language Server Protocol with support from the community.
- 🏃 Continue to refine and improve the Language Server Index Format with support from the community.
- Support type hierarchies in LSP
- Make VS Code available in the Windows Store.
- Improve our smoke tests and revisit the current approach on how we implement them.
- Invest into a unified, improved and fast file watching
- 🏃 Improve our GitHub issue bots, examples:
- reject invalid incoming issues automatically
- 🏃 automate training of our classification bot
- detect issues of limited use that 'need more information' automatically
- Adopt a safe supply chain
- 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
- Refresh all of our dated overview videos.
- 🏃 Modernize the appearance of our website
- 🏃 We'll continue our work on our GitHub bots that enable members of our community give us a hand triaging and resolving issues.
- Ensure we have always good collection of issues labeled
help wantedandgood first issue
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!