Multi-root workspace implementation Roadmap

[egamma]

Roadmap

The forward looking roadmap for multi root support. Work planned for the current iteration is on the corresponding iteration plan.

October

Enable extensions available on the Market place

• Analyze most popular extensions that use the rootPath and workspace settings
• Engage, file issues and contribute PRs as appropriate

[felixfbecker]

I don't see LSP support on that list, what is the plan here?
Context #396 (comment)

[dbaeumer]

@felixfbecker we first want to explore how mutli root workspaces affect our own extensions that run as language servers (see list above) and then decide whether we want to pull the concept into the LSP. For the LSP we need to consider how big the impact will be for other clients and if we not raise the bar too high for language servers to implement that. It is indeed easy for language server that are single file (like html, json, eslint) but get more complicated for language server that are project based (like TypeScript and tslint for example) and gets very complicated for language server that use libraries that have a workspace folder === root project concept (like Eclipse JDT does).

Just as a side node: it is even not easy for TS although TS walks the parent chain to find a tsconfig.json file. If a folder X requires TS 2.2 and a folder Y requires TS 2.4 and they are in a multi root setup then we still need to start 2 servers. So it might be and option to always start a language server pre workspace root folder even in a multi root setup. This is especially true since it would ease resource management as well since the folder setup will be dynamic and not a static property.

[felixfbecker]

@dbaeumer so for the time being, you will just spawn a language server per folder? Just so the implications are clear, that means jump-to-definition etc. will not work across the additionalFolders for at least PHP (which is fine if you want to accept that as an initial trade-off).

[dbaeumer]

@felixfbecker this is not what I was trying to say: we need to understand the pros and cons of both approaches and then decide what we will do.

Commenting on our example I think we need to understand the different use case:

• I have a multi folder setup were folder A and B have no dependencies
• I have a multi folder setup were folder A and B do have a dependency. IMO this needs some explicit project dependency description and should work in a single folder setup as well. We can't not simply assume that two folders pulled together into one workspace do have a dependency on each other.

[fipda]

IMHO loading project A and then B or loading B and then A, should not matter as they remain independent. Which settings are used should depend on the concept of "active" project, much like it was in Visual Studio, visually indicated by showing the root folder name in bold, but could be anything. Switching between projects meant context switching all active settings, for debugging, everything the project contains, as if it was the only project loaded. The only difference is that you see them both on the screen and can switch between them (so both should be loaded in memory to make context switching as fast as possible, including which plugins are active, but settings that are same in A as B obviously do not switching, such as plugins that are used for both A and B).

To make project A and B dependent, an overriding and optional settings file should be stored that effectively becomes project C, but has references to A and B and can contain shared settings that override those in A and B, including plugins and themes, which will make context switching faster because these are not context switched (loaded/unloaded) from A or B. Settings not overriden in C, again are taken from the active project A or B.

When sharing these multiple projcts, only file C needs to be shared, with references to the github repository. when C is loaded and sub projects are missing from filesystem, user is asked if it wants to fetch these (in a list with checked checkboxes, allowing users to uncheck those they do not want to fetch), and targetting either sub folder at the root of the C project by default, or let users browse for an alternative location per project.

Filesystem could look like this:

Project C\
  setting.json
  ...
  Project A\
    setting.json
    ...
  Project B\
    settings.json
    ...

Creating an empty folder C and adding project folders A and B and then opening code in C should be enough to open A and B without any dependencies, but making overriding settings, perhaps by importing and merging those of A and B, requires saving as settings in folder C. When starting code from within subfolder A or B will only open that folder as one would expect. A and B remain independent and their dependency is only known by VisualCode based on settings in C. Projects A and B need not be in subfolder C, but then they must be added to C settings via VisualCode UI or manually in C settings.

[mvestergaard]

Is the concept of a project file part of this?

Meaning a file you can open which loads multiple predefined folders. This would make it easier when working in teams.

[bpasero]

This will continue in July. A first version of release notes for the work done in June is available from https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_14.md#multi-root-workspace-preview

[jlk]

Cool - will give that a spin! One thing @bpasero - In the 1.14.0-insider build I see "Add Root Folder" whereas the first release notes image shows "Add Folder to Workspace..." - might confuse folks.

[bpasero]

@jlk we did the rename today so it should hit insiders tomorrow

[gulshan]

Can there be AdditionalFiles attribute in a folder, just like AdditionalFolders, to access additional files in the opened folder?

[bpasero]

We currently do not plan to add files.

[saada]

I've been using the Insiders edition for the last few days! Amazing work!
The git page is still a bit weird to use... but great start!

[airtonix]

good start. but two things... three really.

1. sublimetext configuration about this concept makes a lot of sense.

2. the workspace definition needs to be in the workspace settings no the user settings.

3. folders is just an array of strings. Does this mean they can be an array of objects? where's the schema documentation for this feature? for example i'd like to do this:

{
    "workspace": {
        "file:///c:/Data/Projects/FOO": {
            "folders": [
                {path: "file:///c:/Data/Projects/FOO/", name: "root", exclude: "server/*, client/*, docker/*"},
                {path: "file:///c:/Data/Projects/FOO/docker", name: "docker" },
                {path: "file:///c:/Data/Projects/FOO/server/Static/Theme", name: "server/Views"},
                {path: "file:///c:/Data/Projects/FOO/client/config", name: "client/Config"},
                {path: "file:///c:/Data/Projects/FOO/client/src/styles", name: "client/Styles" },
                {path: "file:///c:/Data/Projects/FOO/client/src/styles", name: "client/Scripts" },
            ]
        }
    }
}

[borekb]

Is there a more detailed roadmap for August? (So much looking forward to this :) )

[bpasero]

@borekb the entries under the "September" category in the summary are the things we work on during August.

[brunolm]

Is git support included in this release? I mean, can I switch the folder I want git to check for changes, make commits and so on?

[bpasero]

@brunolm we are working on it, the idea is to show all repositories of all folders in the git view if there are outgoing changes.

[egamma]

@borekb @bpasero regarding what is on the roadmap (this issue) and what is on the August iteration plan (#32043). I did some plan "refactoring", the work that is planned for August is now on the August iteration plan . The roadmap captures the work planned for future iterations. Sorry for the confusion.

[boyvinall]

I've got one edge-case to consider for UI implementation - the current stable release seems to break down when you have LOTS of git subfolders. I know this is probably very much an edge-case but it's something I hit whilst working on a genuine project just now.

Here's a little test script for you 😃 which also shows the current resulting UI (from v1.16.1).

https://gist.github.com/boyvinall/cd190baf1871d187f927e9b6093570c5

Ideally, we should not squash the repo name, and we should make the window scrollable.

PS. Really appreciate the great job you guys are doing.

[DonJayamanne]

I've come across a possible issue with multi-root workspaces. Details of the issue can be found here Updates to workspace settings not available immediately in multi-root workspaces.

[bpasero]

I am closing this issue as the work on helping extensions to adopt multi-root is in progress since a couple of days. We are fixing the issues reported (thanks for that!) and keep the documentation updated: https://github.com/Microsoft/vscode/wiki/Extension-Authoring:-Adopting-Multi-Root-Workspace-APIs

Multi root will be enabled for our upcoming stable release early November 🙌

[tylerjwatson]

I'm not currently sure where to write this, so I think this place is as good as any.

I, along with most people have received multi-root workspaces in the 1.18 october update, and this feature is probably one of the best things to happen to my workflow in a very long time It has taken the amount of vscode windows I need to run from 4-5 to just one, and with it all the time saved with switching between them.

On behalf of myself and all the other people out there who this has helped, I would like to take the time to thank the vscode team, and everyone involved for the support of multi-root workspaces. I know it has been a colossal effort, and this message is just to let you know that it has been much appreciated.

Cheers!

[hgl]

in a multi-root workspace, where does ${workspaceRoot} point to? Are there variables that point to each individual root?

[dbaeumer]

The point to the root which contains the file that uses the variable.

[DonJayamanne]

@dbaeumer, if that's the case wouldn't this have the same as the token ${workspace folder}

[dbaeumer]

Yes ${workspaceFolder} is the replacement for ${workspaceRoot} which is now deprecated.