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.