Add support for opening multiple project folders in same window

[stoffeastrom]

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.

[pedrolucasoliva]

Open more than one project at same window it's a important feature for me too. Commonly, I open too projects to copy some base apps. I just install Visual Studio Code and I will return to Atom for this reason

[jtstroup]

+1 I want to show other dev's the value of VSCode, but not being able to open two folders in the same window is a dealbreaker. I hope this gets a higher priority.

[fgarcia]

Just my two cents:

So far the word "monorepo" does not show in this thread

My monorepo centralizes configuration concerns among multiple roots, where each one is marked by a ".root" file in the folder containing them.

Not every root is an external git repository, but they allow partial override of the global configuration.

My main pain point is that the searching for files and/or symbols do not prioritize the content of my roots

[kalinkrustev]

I think the requirement can be split in ~4 separate ones, which may or may not be directly related to each other (and probably implemented independently) :

• support multiple folders in explorer
• support multiple folders in search
• support multiple folders in source control
• support multiple folders in debug

From what I have seen in this thread, separating these can support wider array of scenarios. Of course there should be still some "main" folder, affecting how the configured/selected folders are persisted.

[g13013]

I don't understand why most comments talk about multi-root or multi-folder explorer solutions. Actually I think it is really bad to try to implement it the IDE way. It adds complexity and surely impacts performance (load time, git refresh ....).

I think that this feature is very important, the need basically is to have a visual about all related projects and to switch between projects windows quickly !

We have two choices:

• Implementation in a single window: In my sense it introduces many other concerns, multiple projects roots for git, search ..... THIS IS VERY BAD for the UX and will potentially introduce bugs and complexity to the editor.
• Implement a switch mechanism that is Visual and keep one window per project: this is the safest and more convenient choice for very less cost ! @min20 posted a visual about slack's switch buttons between groups that I find perfect for the need !

I hope this feature will land, but not as multi-root solutions ! one of the key benefits of a small editor is it's simplicity and speed , muti-root != simplicity & speed

[dariusrosendahl]

I have to completely disagree with you @g13013 have you seen Sublime's implementation? It's very simple and still a lot faster then Visual Studio Code. Even with all the GIT plugins enabled.

We are not talking about using multiple projects in 1 editor. We're talking about only using the folders of a project you need.

I'm working on Intershop shops for example. There's a lot I don't need, only the cartridges I have to edit. 80% of the folders and files are useless to me and only make the editor a lot heavier (trust me, it slows down a lot).

Using the "Quick Open" in Visual Studio is also unusable if there are a lot of duplicate files. You often are not sure if you'll open the right one and again, it slows down with a LOT of files.

[g13013]

I understand, but, having using sublime and atom in the past I finally ended to the conclusion that none of them with "muti-root" feature have solved anything else than project files exploring, speaking of sublime, sublime folder tree is very slow in big projects and even freezes when discovering, sublime does not have "git" and "debug" features integration out of the box.... introducing muti-root will introduces a lot of bench of issues related to git integration, searching without impacts on performance ... even UX is impacted, like exploring srcoll issues in big projects.

[dariusrosendahl]

Weird, for me it's the opposite.

Maybe it's because 99% of the time I only include what I need into Sublime or Atom :) and that's exactly what we want.

Maybe it's just the way you use the editor. I'm used to using CMD/CTR + P and typing the exact file I want. This is impossible if you have to include the root of a project with a lot of duplicate files. (cartridges/files left there to compare what the original was :)) or something like wordpress where there are a lot of files with the same name.

[pr-yemibedu]

Hello, Yes the multiple folder idea is fine without breaking many things. Each additional folder can be a new sub section with a prefix to indicate that it is foreign to the primary folder. Primary is used for debugging and Git. A user can right click on any foreign folder and make it primary. What you gain : 1) being able to see all your folders and files and open them as needed. 2) re-homing of what is primary to work on.

Now if someone wants to have multiple projects open at once, then they should have a new issue request opened. That adds significant complexity outlined by numerous people. Plugins do not equate to builtins. If there is an editor that has a matching built-in feature, it should be pointed to so that other developers can examine how their workflow fits with such a feature. Thank you. Good day.

[mduey]

Add me to the list of users that consider this the only deal breaker that prevents me from moving to VSC. I find the Sublime implementation of Projects to be spot on. If I need to work on the "Volunteer Hours" app for example, I open the project which I have populated with different folders (the main project folder as well as another folder that contains images). That is my working set for that project. If I need to flip over to the "Exchange Calculator" app, I can swap the whole working set to that project or open a new window with that project in it. Another use case is when using a CMS. If I am working on a plugin for the CMS, I can have one project for the plugin that is a Git repository and another for the whole CMS, which is not Gitified. I can flip between the two as needed and keep my Git concerns separate. VSC looks like the future to me, but not without the ability to keep separate working sets of folders.

[pr-yemibedu]

Hello, I have only seen that Sublime Text has support for projects with a project file. How does that equate to what is being asked for here? It sounds like a request for vscode to support project files within a workspace. There was a comment earlier of an extension that could handle things in that regard for a project manager.

I do honestly also use Atom and I use the multi folder function (built-in) that allows me to have documentation folders and my current project folder open at the same time. It really seems like lower hanging fruit to just enable primary and a bunch of secondaries. Probably a simple arrow or start to indicate primary. Thank you. Good day.

[Srekel]

For what it's worth, here's my use case. I work on a game which is divided into three repositories; one Git repo for the engine, one hg repo for the game code+content and one hg for game code that's generic over many projects. There's also one hg repo for the company's Sublime Text plugins. The generic repo is a subrepo to the game-repo.

At my next work place, I expect to work with many repositories again.

It's super convenient to have all of these in the same editor instance, and I think it would make sense for all of these to get proper SCM in VS Code.

I would expect search to search through all of the mapped folders by default. A nice bonus would be to be able to switch on/off which folders to search for, temporarily. (For example, when I'm only interested in finding things in the game engine)

There are a lot of people saying that VS Code shouldn't have support for this because A) They don't need it and B) VS Code is a simple text editor. The first reason is no good - there are few features that are used by everyone. The second reason... VS Code is not just a simple text editor, it has debugging, SCM, plugins. Other "simple text editors" such as Sublime has multiple folder support. And as someone who is adamant about performance, I can't see how adding this feature would affect performance in any meaningful way, especially for people who only use one folder anyway. Can we please focus the discussion on how we want the feature to work rather than why we don't want it.

[pr-yemibedu]

@Srekel can you include a screenshot of how you work like this in your current editors? It sounds like a mix of folders and projects using built-in and plugins. Hopefully people in that A camp would hardly notice changes to incorporate this kind of feature. For the B camp folks, they are right. You can do things quickly with the application out of the box if you do not need to be bogged down. Holding close to that probably helps to have such quick update cycles and uncluttered interface elements.

Some things about how to accomplish this include:

• understanding the relationship of scope, context, session, views and being current.
• the upper limits (more that 256 folders?)
• key effected areas (editor tabs, settings, scm, git, extensions).
• workspace setting override or conflicts.

It would be nice to here about some of the things VSCode takes for granted in these areas that need compensation. Thank you. Good day.

[codapill]

+1

[mhzed]

+1. I have 30+ modules each with an own git repository that I'd like to have access to and work on in a single environment. I thought that's what most js/node developers do. With VSCode this is impossible, a deal breaker for me regretfully.

[Jeyanthinath]

+1

Its been open since 2015 and still not fixed yet. Its a simply most wanted feature in any editor , but sadly vscode not having it .

[kdumovic]

+1

I'm constantly confusing one VS Code window with another when command tabbing.

Every other editor I know of has this (Atom, Sublime, Brackets...)

Adding a symlink to my project is a hack and would require me to update my .gitignore. Opening the parent directory is annoying because then my files pane is flooded with other projects I don't care about.

[gulshan]

April iteration plan showing the task " Investigate into multi-root, multi-folder workspaces" as done. What are the results of the investigation? @bpasero @tyriar

[vulkanosaure]

+1

[gulshan]

Sorry if I'm being too eager. You guys are busy releasing code now.

[pr-yemibedu]

Hello, The Open Folder dialog should be considered to be Open Folders. So if I am under a particular parent folder, I can in the dialog highlight two or more of its sub folders to open at the same time. That would be a welcomed addition with incorporating this feature. Thank you. Good day.

[oooeeee]

+another one

[samhh]

Never seen so many low-effort comments in a GitHub thread before, especially post-emojis. Goodness me.

I'd really like this feature. As someone else will have said already, many modern projects are modular e.g. frontend in one repo/project and backend/api in another. You'll often want to work on them together as one.

[intijk]

This is the only reason I haven't give up Atom.

[martinjco]

Microservices and serverless platforms, combined with the long-standing "repos are cheap" mantra, are why this is a must have. It's not unusual to have ~30 [small] repositories open and be working on files from multiple projects concurrently; expecting people to switch between that many windows, or offloading the file view arrangement to the desktop environment window manager is not going to work.

[pr-yemibedu]

Hello, How do you manage your 30 repos now @martellaj ? That sounds horrible to be working live with that many files open. I tend to have a lot of libraries I work on but was I get a significant need to work on backporting a useful feature to be shared, I on purpose close all my other edit windows. I create tests update configuration files and project options to make I work, then I go back to my prior view. That is still maybe 3 or 4 other windows. Are you doing this because of other limitations in your environment? maybe the programming language does not have intellisense? Maybe an extension that can read the API to give you functional signatures would help? A language like F# has a feature called type providers, one of which can do just that and make programming the web easier. This is not to diminish your need for multiple folders, just that you would probably still have at least a handful of other issues with such a large active workspace. Thank you. Good day.

[dariusrosendahl]

@pr-yemibedu, I think what @martinjco is saying is that he doesn't have the files open but he would have quick acces to the repo's if we had a multi-root structure. Imagine, just CMD+P to any file you need ;)

The problem with the current situation is that we HAVE to have the files open or at least switch between the 30 different windows because VScode doesn't support it.

I actually switched back to Atom recently because of the missing feature. I'm working on a project with 9 repo's at the moment. I won't want 9 VScode widows open at the same time, but I just want to use a shortcut to go to the file I need.

[nuno1895]

Agree with the Comment by @dariusrosendahl. I am a newbie coder and I have to reference older project to write new ones. Hopefully, that will change soon but in sublime I can easily have three to four project folders and compare have them open in the same session

If we can get that in visual studio that would be great

[pr-yemibedu]

Hello, I agree with the points made as you can see my previous posts favor this feature. There was an exact statement I was commenting about by martinjco :

It's not unusual to have ~30 [small] repositories open and be working on files from multiple projects concurrently;

What nuno1895 shows is how I use Atom today when I need to work on multiple folders but a simple main focus project. I do in fact use both as well as VS2015, gedit, vim, notepad, and notepad++ for active development. There are strengths in each that have no equivalent yet in their counterparts.

I was just trying to understand if there was a core point that can be made clear. We all want to get this worked on and favored by the developers who would spend time on it. That is why I was asking how this is handled today. 9 vs 30 probably would not have struck my interest as much to respond but I like to know what people are comparing to vscode and if it is worth me even looking at another tool.

I have only seen Atom and SublimeText spoken about as the basis for comparison and with useful screenshots. More discussion, thumbs, and feedback are welcomed to get this accepted and implemented. Thank you. Good day.

[mduey]

One point that may not have been emphasized enough is the ability to quickly "flip" between folder sets (projects). It's called "Quick Switch Project" in Sublime. When you click that menu item, you get a pop-up with a list of all your projects, when you select one of the projects, the editor displays the folder(s) and all your open files as you last left them.
For example, if I was working in Project A and had the app.js and index.html files open and then switched to Project B, it would close Project A and display Project B. If I then switch back to Project A, it will show me the folder(s) and the app.js and index.html as I had left them (even unsaved edits are there). If I need to have both projects open at the same time, I can just open two instances of the editor. The key is that I am able to keep all my stuff in separate buckets and I can switch between them fast.

[ventusjk]

+1

[pr-yemibedu]

Hello, I read about that feature. Switch projects without browsing in Sublime Text points out some of the good and bad. It would be nice to maybe encode the multiple folders open in the workspace settings file. If that file seems the wrong place, then something like folders.json can be created to persist the current state of what folders and files are available and open for the current working set. Thank you. Good day.

[logidelic]

I started using VSCode a few months ago and, generally, I'm very satisfied. I'll add my voice to the choir and say that this missing feature is the big head-scratcher for me. Are there any other decent editors that have this limitation? In any case, it should be fixed. :)

[Srekel]

Here's the setup at my new job: One repo for the core tech. Say path is C:/mygamengine/ One repo for the game code. It's synced to C:/mygamengine/mygame One repo for the game's content (textures etc): C:/mygamengine/mygame_data

All three are git. They aren't set up as sub repos, they're just synced to those folders.

Preferably I'd like to just open the root folder in VS Code and have it automatically figure out it's essentially three different projects, and that files under mygame belong to that git repository and not the one in mygameengine.

I'd like to be able to set settings for this workspace that are different for each repository (for example, I might want to run a linter on the engine project but not on the game code). It would also be nice if workspace settings by default was set on all the three projects.

[edwinramirez]

Wow, this still hasn't been resolved? I was hoping to replace Atom with VS Code since, according to reviews, it is much faster and doesn't lag as Atom does. My main project is two Git repos, one back end and the other a front end. Locally both are in the same folder but if either Atom or VS code opens that parent folder then no Git status is recognized. In Atom I just add both folders to my workspace and just works.

[Tyriar]

:sparkles: Update :sparkles:

It's been a while since our last update so I thought I'd bring everyone up to speed. Myself, @bpasero and the rest of the team have identified most of the issues with implementing multi-root and are currently working on some mock ups and figuring out more specifics of the UX.

Why is it taking 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. For starters all components within VS Code were designed under the assumption that there is only ever a single folder or no folder opened at any given time. When you have an codebase as large as ours with an assumption like this, it takes a lot of work to make it more flexible.

To give some examples, here are some of the bigger pain points we've identified so far:

• The extension API exposes a single workspace.rootPath, this is insufficient when we add support for multi-root folders. We want to avoid breaking these extensions and provide a migration path if necessary.
• The way workspace settings interact in a multi-root world is a little different. Take workbench.statusBar.visible for example which is currently allowed in workspace settings. We would no longer be able to support this as it would lead to strange/buggy behavior if defined in 2 folders. We're in the process of finding out how to deal with these sorts of cases.
• The SCM provider (git) needs probably the largest amount of UX work in order to support multiple folders: Do we need to introduce the concept of an "active project"? Should is be explicitly set (right click the folder and set it) or should it be implicit (looking at the active file's folder)? Should it be a global concept or limited to that specific feature? etc.

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.

Summary of comments to date

I just spent a few hours going through the enormous thread to collate the feedback so far. It was a little tough to categorize some of this stuff, but here's what people were after in general (I'm paraphrasing).

• I want git integration across multiple folders
• The current folder switching and/or OS window management UX is cumbersome
• I want to search across multiple folders
• I want to debug across multiple folders

Concerns

• Do refactorings work across projects or on a single project?
• Which project am I committing to on Git?
• What folder(s) will my search running in?
• Don't break workspace settings
• Don't break extensions - warn extension developers about new API
• A Slack-style tabbed UX is not enough for me, that's essentially just moving window management from the OS to VS Code - I want to be able to access all files from the projects in a single Window (ie. set of editor groups)
• "In my sense it introduces many other concerns, multiple projects roots for git, search ..... THIS IS VERY BAD for the UX and will potentially introduce bugs and complexity to the editor."

Other comments

• I only want to open a subset of the repos in my "git folder"
• I want a nice way to search in a single folder or organize search results by project
• I want to be able to navigate to dependency code to read quickly
• I want to run different versions of TypeScript for different folders
• VS Code is too slow with giant repos
• I want to keep some projects always open to use for reference (eg. a theme/template)
• I want VS Code to recognize .vscode/settings.json files in any directory (this would help workaround)
• Let me define a project root (search/debug) and a git root
• Sublime handles multi-folder git integration elegantly
• Tabbed folders similar to Slack's UI (ie. some active project paradigm)
• A separate section in explorer for each folder
• Use a folder as primary and the rest as linked/sub-folders
• I want quick switch project like in sublime (fast switch + retain the workspace layout)
• This style of workspace management is particularly useful for the following: npm module, julia, heroku PaaS, wordpress, drupal

Current workarounds

Here are the main workarounds currently:

• Opening a mutual parent
• Git Project Manager
• Project Manager
• Symlink the folders as sub directories of the "master folder"

When to comment?

Please avoid :+1: or "I want this" comments. When a comment is made on this issue, the 153 and counting people that commented on the are notified in addition to many more who hit the subscribe button. Commenting will also bury team updates so try to be mindful of that. By all means comment if it adds to the conversation though.

[tal]

A feature that would have more use arguably than having multiple roots is to add the ability to have configurable working sets. This would enable you to open a mutual parent, but have many combinations of folders within this project.

Generically this would be useful for any project for being able to "focus" on certain files/folders at a time in larger codebases without having to change the config for the whole root each time.

[jackie-qiu]

NO plan about this feature?

[andressltz]

You can see the plan for this feature on @Tyriar's comment and in this related links: https://github.com/alefragnani/vscode-project-manager/issues/46 https://github.com/Microsoft/vscode/issues/26068

[stevencl]

We would like to share our designs for this and get your feedback. To do this we are going to set up a number of conference calls where we will walk through our designs and discuss your reactions to the designs.

If you would like to take part in these discussions and help us get the design right, please contact me (send me email - stevencl at microsoft dot com) and I will set these up.

We are hoping to schedule these discussions for Thursday 1st June and Friday 2nd June.

[svipas]

@Tyriar @stevencl Thank you guys! :clap:

[stevencl]

Thanks everybody for joining the sessions today. The recordings of the sessions have been posted here

• group 1 - https://youtu.be/48Y6tB3DN1g
• group 2 - https://youtu.be/kHL6Rt-dLm0

Please watch the videos and share any additional comments you have on the designs.

[bpasero]

@stevencl thanks for running the studies and making them available!

[borekb]

Great videos, thanks! Some feedback:

• 👍👍👍 for the overall simple design and natural extension of how VSCode works today. You guys dealt with many complex situations in a simple, elegant way. Kudos for that!
• I like the aggregated SCM notification in the bottom left corner, no change needed from my point of view with one exception: I'd skip the popup after clicking the SCM notification and go straight to the SCM panel. Fewer clicks = always better for me.
• Color-coding roots like Alexey suggested is an interesting idea, could help.
• Search: scoping to a folder will be important to me, I guess the current "files to include" field could be used for that just fine, just wanted to make sure.
• The only thing I'm not sure about is persistence and opening all the additionalFolders when I open the path. It sort of makes sense with the last example where express-project is clearly the "master project" but I'm not sure about the previous example: express and express-plugin felt equal, like true siblings, and I'm not sure I would expect opening express would also open express-plugin.
  • In a way, the data structure behind this feels like it should be just a flat list of paths, not one "path" and then "additionalFolders".
  • I'm not sure if the concept of one master path is that useful. In my projects, it's probably not.
  • To open multi-root workspace, I would expect a top-level command like File > Open workspace besides the current File > Open folder.
  • Overall, I am not too sure about this. Sorry I don't have more concrete suggestions.

Thanks again, with this, VSCode will gain new super-powers 😄.

[maddouri]

Thanks for sharing the videos. I would like to support the "one section per root folder" design:

At first, I was expecting the other (sublime-text-like) design, but after seeing the "one section per root folder" alternative, it became clear to me that this approach had the following advantages:

• Clear, unambiguous distinction and separation between folders (especially if I have more than 2 or 3 of them, which is often the case when I use other editors and IDEs)
• Enforces the notion that a root folder is a separate (sub)project
• Quick access to sub-project commands (such as "new file", "refresh"... and, perhaps in the future, right-clicking to launch a task (e.g. "rebuild") on that specific sub-project ;) )
• As mentioned by the 2nd group, with this design, it is less probable to have the folder-name-truncation issue

[TurkeyMan]

Regarding the "one section per root folder" concept... I'm really not sure this will work well for me and most of my use cases. Whenever I have a multiple-root situation, it's common that I have many; not just 2 or 3. I'm not sure how this approach will scale?

[borekb]

Also some argument for the current folder-like layout is that it is consistent with how a monorepo would be displayed. For example, compare:

monorepo/      <- contains .git
  project1
  project2

vs.

microservices/
  project1      <- contains .git
  project2      <- contains .git

Those two should really be treated quite similarly by VSCode: monorepo already is (committing: natural, search: "files to include", multiple READMEs: their folder is displayed in editor tab; etc.). Multi-root should follow this as closely as possible, IMO, which the current design does very well.

[borekb]

@stevencl One thing I didn't completely understand: will the solution bring scoped (or even hierarchical) treatment of .vscode settings? Like, if I had .vscode per top-level folder, will those settings be applied individually? Will they be somehow aggregated at the project root? Or will only the "primary" .vscode count?

[pesho]

I prefer the "one section per root folder" design, for the same reasons listed by @maddouri. In addition, having used the other alternative (in Atom), it's visually harder to find where a new root-folder starts when multiple highly-hierarchical folders are open and expanded.

[BTMorton]

Thanks for the design updates, it's looking really good!

Is there the possibility for having multiple workspaces available at once in the UI? So that you could easily switch between them. For example, you have something like:

EXPRESS, EXPRESS-PLUGIN
  express/
    lib/
    test/
    package.json
  express-plugin/
    lib/
    test/
    package.json
CONNECT, CONNECT-PLUGIN

And then clicking/double-clicking on the CONNECT, CONNECT-PLUGIN divider would switch to having that as the active workspace. This would allow easy switching between workspaces for people who have to deal with multiple set of projects. I'm not suggesting that they all be available for search and SCM and whatnot, that would remain with the current workspace which is the currently expanded one.

That could then work with having the root folders highlighted as suggested in the first group, and perhaps having the new file/folder icons be available when hovering over those folders.

Some feedback on the settings JSON, might it be useful for the workspace settings to be something like:

workspaces: [
    {
        name: "Express Project",
        root: "file://C:/workspace/",
        folders: [
            "./express/",
            "./express-plugin/"
        ]
    }
]

So then the root becomes the source for opening the folders, rather than the path, but the root itself is not opened, only each folder. You then don't have a "primary folder", but still keep the relative file paths. This is assuming that you can open a pre-defined workspace through the UI, as opposed to opening the root folder and all additional folders with it. The name can then be used as the divider preventing large numbers of folder names making it too long, or unhelpfully shortened.