News
VS Code Finally Gets Multi-Root Workspaces
Visual Studio Code development is marching on to its steady monthly release cadence, knocking off user feature requests one by one, with multi-root workspaces topping the latest iteration.
Nearly two years after the feature was requested, it's now enabled by default in the stable release of Visual Studio Code 1.18.
Multi-root workspaces let developers group a set of disparate project folders into one workspace, instead of having to work with files and folders residing only in a single root folder. This provides a variety of advantages and use cases, such as working on multiple projects at the same time -- say a project's documentation and its source code repositories -- and keeping everything in sync.
"It's the moment you've all been waiting for, the most sought-after feature is finally hitting stable," Microsoft's Brian Clark said in a video. He demonstrated the feature's use, showing how a developer working on an Angular project can easily add the folder for an API project that supports the Angular project's UI. That creates a workspace showing the root folders of both projects. After folders have been added, the workspace can be named and saved and developers can switch back and forth among workspaces through a variety of UI interactions.
[Click on image for larger, animated GIF.] Multi-Root Workspaces in Action (source: Microsoft).
As Clark said, developers have been indeed been waiting for the feature, as it was first proposed in November 2015 with an issue titled "Add support for opening multiple project folders in same window" that said: "Right now it doesn't seem possible to opening multiple project folders in the same window which imho is a bit constraining. If you are working on modular modern projects it's a must have to be productive."
That issue garnered 377 comments, one of them from Microsoft's Daniel Imms explaining why it took so long. "It's taking so long because this feature is not our only responsibility and the work involved in making multi-root happen is quite immense," he said in May. "We do not want to rush out with a poorly thought out solution so we're taking our time and really thinking through the potential problems and implications with how this will affect each component. It'll come when it's ready."
His post serves to illustrate some of the many complicated details that a programming team must consider when users ask for a new feature and then wonder why it isn't soon implemented. One of the considerations is working with other moving parts, such as getting VS Code extension authors on board. Details on how to adopt multi-root workspace APIs when creating extensions are available here.
Another popular feature request -- showing Git status in File Explorer -- was also addressed in the October release. Also posted in 2015, this request sought Atom-like functionality in which new files, modified files and ignored files are identified by different colors.
Now, the VS Code File Explorer shows modified, added, conflicting and ignored files in different colors and with different badges.
Fulfilling yet another popular user request, VS Code panels can now configurable, letting them be displayed in a vertical layout, for example.
Other new features were also prompted by user feature requests, not the least of which (or actually maybe the least of which) is reverting the color of the VS Code logo back to blue after a vociferous developer backlash followed Microsoft's attempt to make it orange.
Other changes to VS Code 1.18 include:
In case you're wondering, Microsoft detailed future plans for VS Code in a roadmap.
Also in case you're wondering, the No. 1 feature request for VS Code (at least when measured by the number of "thumbs up" votes) concerns updating extensions that are installed, removed or disabled without restarting the editor.
When measured by the number of comments, the top outstanding issue is "Add VCS Subversion Support," also posted in November 2015.
About the Author
David Ramel is an editor and writer at Converge 360.