Vscode: Add support for opening multiple project folders in same window

agree, but maybe it is a optimize solution for memory

+1

I'm not sure I understand the ask; its a lightweight code editor, not an IDE ... why would you need to open multiple "project" folders that aren't hierarchical (where you could set the working path to a mutual parent)?

If you're working on modules that are disparately stored on disk that are somehow interacting with each other to that degree, then they are too tightly coupled to begin with... are your projects siblings? If so, just open the parent folder, or parent / parent folder... wherever the root of your "solution" is.

Well, if you have a number of modules (which are all in their own git repository) that is independent of each other but you have one repository that uses those dependencies it makes sense to be able to open these independent folders and make changes that would be reflected so you can test it locally. That would still be a lightweight code editor but a more useful one imho!

The main issue with setting the project as the parent is that git integration goes away, there are other valid use cases beyond both having a mutual parent as well though.

@stoffeastrom sounds like a use case for submodules; I'm not sure how your project would reference another, unless you were aliasing with some mechanism, such as npm linking, etc. This problem is what package managers are largely intended to solve. If the modules are tightly coupled, then they really aren't isolated modules. You wouldn't be able to reliably make changes to support one project without worrying about the change having consequences for other consumers down the road. Even with submodules, they are read-only by default for exactly that reason.

At any rate, what @Tyriar just mentioned is one of the reasons I am wary of having this type of multi-working path interface in a single instance/window: you have to handle integrations (like git), extensions, refactoring, debugging, etc, etc, etc. all in some isolated fashion. For instance:

If I use the git integration to commit, am I committing project A or project B?
If I refactor a class name in TypeScript, should it refactor in project A or project B, or both? What if the same class name exists in both projects with different meanings? What if one is loosely referencing the other?

These are just some examples of how something seemingly simple can get very complicated, very quickly. I think it would be way more confusing and, frankly, less useful than to alt-tab/cmd+tab between a few separate instances of VSCode, each happily managing their own isolated working path without all the extra effort and edge case issues.

Im not saying that it couldn't be solved, but I don't quite understand why switching between multiple windows and/or instances is an issue. Maybe I am missing something...

Sublime, Atom, Webstorm - they are also "lightweight" code editors (except maybe Webstorm) and they allow opening multiple root folders from different locations. These editors are probably 99% of what web developers use.
Code can compete with them with much better Typescript support (and it will be very popular consider Angular 2 is comming) but only if it will give developers what they use now as a basic functionality.

+1

+1

As a Go developer, I find this feature extremely useful in Sublime or IntelliJ Idea. For instance, my small project imports code from Go core library or may import some 3rd party library. So I need to be able to quickly navigate to them and read that code.

+1. Multi-git repo microservice solutions are very painful in VS Code right now, thinking of finding another Typescript-capable IDE instead.

We definitely need some sort of 'solution'. I'm a native dev, and this almost always involves building a set of libs/dll's and then referring to them from some host app project.
Once we have multiple projects, we also need a 'startup project' for when we press 'run'.

I would also like support for projects and multiple git roots. The code I frequently use is found in several git repos and being unable to switch between them without closing my current workspace and opening another just to turn around and close that one to open the previous is exhausting. If I add the parent folder where all my repos are housed then I gain the ability to navigate and search among my files but I lose git integration. It's a real bummer.

The line between "text editor" and "IDE" is pretty dang blurry and I don't really care what VS Code is labeled as. What I do care about is what a tool can do and how painless it is to use. I think adding project support would alleviate a lot of friction for folks like me.

I also would like to see the git integration work when your workspace contains multiple repos, but I just want to make sure folks like @Loren-Johnson realize they can have multiple vs code windows open simultaneously.

This is in response to: "unable to switch between them without closing my current workspace"

You mean #2686 is a duplicate of this?

Sorry, I misread the description and reopened this one.

+1

Is there any progress on this issue, or at least some statement if this will ever be implemented? Are there some low-level decisions in the code that prevent multiple roots in one project?

This is pretty much the only reason I'm not moving from ST3 to VSCode.

+1

+1

+1

+1 this would be very helpful. The suggestion to use git submodules is very inconvenient. Would love to have this feature.

An initial lightweight approach would be something similar to what git-project-manager extension does. The approach could be to basically switch the context/root for what git sees as changes, but without changing the context/root for what file browser sees. This extension works perfect, just needs a tighter integration to make the switching faster.

+1

+1 - I started going down the path of using git submodules, but it feels like more of a hack than an actual solution.

+1

+1

I'm using git-project-manager extension to switch between folders, but would really love to have an option to open several folders at once.
+1

Just want to say that the owner of Project Manager extension is waiting on this Issue as well.

With regard to some of the comments (above), I just want to say that we're all different, we all have our particular ways of executing our work on our particular projects. That fact makes UX more important than it already is.

We all knew that "Open folder..." was just the first baby step to inevitably having project management in vscode with things like "Open project...", and so forth. Just like all the other editors out there, especially SublimeText (which is where I've come from).

For me, this issue is an improvement to the UX of the product. And we all know that UX is king.

I almost feel like this kind of stuff should be the law, and therefore the tag "feature request" should instead be "feature reminder".

This issue should be top priority over any other issues in vscode. Not only because UX is king, but because I'm not experiencing any other issues with vscode right now other than this one... technically.

I originally was browsing to ask that Microsoft just take over these project-like extensions and integrate into VSCode directly, and improve it's UX, say for example by adding "Projects..." to the menu.

Thanks,
+1

+1

My use case for this feature is described here: #9515. (It was closed as a duplicate of this issue.)

I hope this feature happens!

+1

@poidl,@mastrauckas, @mdedgjonaj, @alanleite, @Xcorpio, @mibanez, @josebalius & @brusbilis:
A while back GitHub introduced the lovely "Add your reaction"-feature (see the smiley on each upper right corner of a comment or the issue itself?).
Those serve the purpose of informing the VSCode team about your interest but prevent meaningless +1 comments. It also prevents other folks who subscribed a certain issue or MR to get a notification and therefore saves valuable time. Another bonus is that issues/MRs can be sorted by most reaction which makes it instantly visible for the VSCode team what is relevant to the users. On top of that there's even a Uservoice for VSCode.

This comment itself is meta and therefore meaningless too. I'm sorry about it but I thought it was necessary for educational purposes. Every direct reply to this comment (=more meta) will result in me blocking the user.
Let's exercise by only reacting to this comment by using the reaction feature!

To @poidl s answer: Then don't reply at all!

I don't see that smiley. At least on mobile. Happy blocking!

@poidl yes the reactions feature is not available on the GitHub mobile site unfortunately (along with many other features). You can get to it on mobile by hitting the "Desktop version" button at the bottom of the site.

@dj-hedgehog's advice is spot on though, GitHub reactions allow us to gauge community interest in something more effectively than comment count. Additionally, we're planning on deprecating User Voice so GitHub issues and reactions are our source of truth for feature requests.

+1

+1

My solution to this problem: create a symbolic link to my project root.
So if I have:
project/modules/gitmodule

I go into my gitmodule folder and do:
ln -s ../../../project .project

Now I can open my gitmodule folder in vscode and still have access to the parent project folder.
I use a dot in the file name so it sorts to the top of my list in the explorer.
Obviously, I would rather not have to do this, but I figured it might be useful for some of you.

Almost forgot: don't forget to add the symbolic link to your .gitignore

+1

This is a really important feature to a modern text editor. Please solve that "problem" please.
For a while, I have had to copy and paste all of directories that is used to my actual work folder and this in Sublime Text is so Trivial.

Project > Add Folder to Project at Sublime Text increments a new path to the Json structure.

Look bellow:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

When working with chef for example, it is common to see a folder structure like:

└── cookbooks
    ├── cookbook1
    ├── cookbook2
    ├── cookbook3
    └── cookbook4

Where the cookbooks (cookbook1 for example) under the root folder (cookbooks) are the independent git repos. This is very common. Now you have to work on cookbook4 but it includes cookbook2 and cookbook3. You will often need to open all 3, either to simply refer to code or to actually edit or refactor code in all 3.

The 2 normal (not symlink hacks) options present issues that no developer wants:

1. As mentioned above many times, you would have to now open multiple windows (not good)
2. If you open cookbooks as root to see all 3, you lose git integration as cookbooks folder is not a got repo (also not good)

+1, Eclipse IDE user here which has feature full 'workspace' control.

Visual Studio Code is not an IDE. It is a light-weight cross-platform editor, like Atom or Sublime. Eclipse, Xcode, Visual Studio, et. all are behemoths in comparison.

Sorry, I am not sure if you are arguing against or for this feature...Atom, Sublime, VIM, Emacs allow you to open multiple folders in one instance. Light weight or not it's a good feature, IntelliJ IDEA - an IDE - for example does not allow you to open multiple projects still.

@dmccaffery the features being asked for here are not just IDE features, The features being asked for are common to all of the _editors_ you said Visual Studio Code is _like_.

Atom, Sublime, and other lightweight editors can all open multiple folders.

I, personally, don't care if this feature ends up in the product or not -- I understand why some folks want it, but I would point out that it does make everything slightly more convoluted. For instance: when searching using a regex expression -- which workspace am I searching? one? all?

What if I have one folder containing a nodejs project where my tab width is typically 2 spaces, and one folder is a dotnet project where my tab width is 4 spaces? Code would need to be aware of the workspace settings for each folder and maintain context throughout.

These are just a few examples of where multiple workspaces within a single instance can be difficult. All I'm saying is, this feature is far more involved than just having multiple paths show up in the explorer.

@dmccaffery no more convoluted than sublime and atom. This should all be configurable, even the per workspace tab widths. Search in atom and sublime can be in current file only, in this workspace, etc... it is your choice.

Here is a fact, like it or not and it has nothing to do with what you or I want. If other similar software at similar price points (free in this case) have better or more features, and the developer neglects this fact,.. this software will be left behind.

I for one would not want to see that happen to this editor. I think this editor has very good potential and can remain relevant for some time _if_ the developers listen to the wants/needs of it's user base.

Again; i'm not arguing for or against -- just keep in mind that this is a very new editor with far more out of the box context than its competitors -- give it some time.

Even in your example with chef and git integration -- how do you maintain context as to which repo you're committing to? The current UI would need to adapt to constant context-switching -- same for OmniSharp, which is using a server and roslyn to provide syntax highlighting, etc. for CoreCLR projects. The implications are far reaching and will need to be very well thought out.

No argument on the idea that features need to be well planned and thought out. That is a given I would think. I think all users would be happy if the answer here was "it is on the roadmap" or "we are working towards that end". All I am saying is that a "no" would probably kill off quite a few users over night.

As to context switching and git repos in chef, yeah agreed... this is all true and all already accomplished in other open source editors. You know the great thing about open source,,, it's open! Look at the code, get ideas, heck even use some of it (make sure to include licensing as needed). That is one of the great things about foss (free open source software), collaboration and knowledge sharing. Since this editor is already using atom code... I would think this would also be a given.

I found this mentioned in https://github.com/Microsoft/vscode/wiki/Roadmap

VS Code is a young product and there still missing features and experiences that you are asking for and that we want to deliver.
....
....

• Multiple folders inside a single workspace

I think no one say that this feature are simple (as all of us are developer, we can aware what need to be change) and I guest people comment on this ticket just want to show how important it is, how priority should it be, and how to compare this feature vs some VS Code brothers (Atom, Sublime for example).

But because this already in the road map (anyone can confirm that the wiki page still correct) we should discuss about how to implement this instead of just saying how we need and how important it is (as again, I guess VS Code core team already know how we need it and how important this feature).

I not familiar with VS Code source code, can any one tell me if I want to implement this feature, where should I look first? At the first step I just want to open multiple folder and show it on the left bar.

@nvcnvn it's not as trivial as it may look to implement this as a lot of vscode assumes that only a single folder can be opened. As such it will need to go through UX and likely touch many parts of the codebase, potentially with impacts on the extension API as well.

I remember when Atom came out, with the same _single folder_ limitation. The complains were also the same, specially the comparations with Sublime. Then, when _multiple folder_ support was released, some packages(extensions) were broken, due to the new API. Others didn't broke but also didn't support it as well. It took some time until it became _stable_ in the entire ecosystem.

As @Tyriar said, there will be some UX and extension API impact, and will probably be a busy _Insider_ release for core and extensions developers, to adopt the new API.

So what exactly is being argued here?
I mean all I see is "don't make improvements because it could break things"...

Hint:
ALL IMPROVEMENTS IN CODE CAN BREAK SOMETHING!

That is the point of debugging, refactoring, pre-releases (alpha, beta, rc, etc...)
Come on, seriously? I never ever met a serious programmer that was afraid to improve code because it might break something. Be cautious yes, take your time and be safe yes, but never say "no, it could break things" lol

@ddreggors I'm not arguing, I'm simply stating some information about the issue. I said what I said so that @nvcnvn doesn't attempt to construct a PR for this as this will need to be done by the team due to the list of stakeholders.

As @nvcnvn pointed out, this issue is on the roadmap meaning the team will be looking at it soon. We're a relatively small team though with a lot of stuff to cover so some things need to be delayed.

@Tyriar Understood, I just keep seeing these comments from several people that seem to suggest it is best not to add this feature for one reason or another. The worst of which was due to the fact that code is not an IDE, when others clearly compared other editors not IDEs. It made me want to get to the root of the fear of this change to get past it if possible.

I can understand the worry of that PR not being complete, however it could be a good start... merge that change in to a branch and use it as a base. Use that to see breakages and fix them.

@ddreggors it would be wasted effort for anyone to touch this before it's been discussed in one of our UX meetings

Fair enough, you would know best on that end. It is nice to know that this is being discussed though. :-)

Thanks for efforts, and what looks like the start of a very good editor.

It also seems to be a wasted effort to suggest this topic for your UX meetings :–)

I temporary switched back to Atom as it has become much more stable in 1.9 release. It used to crash when any large file was opened and that was the main reason at started checking out VSCode at some point. Really looking forward to see multiple projects in one window – seems like I've got nothing to do but following this thread until then.

Why Microsoft people not concentrating on this ?

+1

+1

I really love VS Code. It's become my primary editor, but the difficulty of working in more than 2 projects at a time is becoming confounding. There's a double whammy on these two open issues: this one, and configuring title bar information.

Either one of these features would solve the problem (though ideally, I'd like both!). I don't mind putting everything I work with under a single folder and opening it -- but then git integration doesn't work, and there's no trivial way to search just within one project or organize results by project.

I don't mind opening each project in a different physical VS Code window and let my OS manage the instances -- but because the title bar shows the open file name first, rather than some root folder/project identifier, it's impossible to switch to another specific open project without opening and looking at each active instance. It makes something that ought to be effortless into a constant annoyance.

Please - is there any way that adding one of these two features can become a priority? I've tried everything I can think of to work around it, I even spent an hour looking for some Windows taskbar alternative that would let me pick windows from a list that could show more of the text in the titlebar but I can't find anything.

If anyone has any suggestions for how to manage multiple open VS Code projects effectively I would love to hear them.

Important thing that works well in Atom is that plugins, such as eslint, should still work at a project level. So if Project A has its own eslint rules, Project B should not be affected by those rules and vice versa. Cannot wait to have such UX in Code. This is definitely one of, if not the biggest adoption hurdles right now.

This is the only thing that is holding me to adopt it.

I know that you may have a lot of other issues to fix and other features to implement, but, at least some basic support to get started would be awesome.

Thanks for the hard work on VSCode!

+1

Until this feature is implemented (if ever), may i suggest that you simply add ability to configure the title bar to show the project name before the file name. This way it will at least be possible to distinguish between the different vscode windows that are open for the different projects. See #1723.

This is a show stopper for me too. I see some devs are wondering why you have multiple git repos at once. This happens with almost any language that uses third part modules. Just look at php - composer, js - bower, node - npm, golang etc. It is very common to start a project which uses some of your modules and you want to edit and commit the changes in the scope of the project.

Is there at least support for recognizing .vscode/settings.json in nested directories. When working on a single project, there may be subtrees with different sets of settings and which come form different (git) repositories. e.g.

root/
    server/
        .vscode/
            settings.json // <== affects all files in the server/ directory
        code/
            tsconfig.json
            foo.ts
    client/
        .vscode/
            settings.json // <== affects all files in the client/ directory
        code/
            tsconfig.json
            foo.ts
    .vscode/
        settings.json // for any file not in server/ or client/

I would expect that vscode would take (and maybe merge) the settings of the closest parent directory like a lot of config files (.eslint, .gitignore, .editorconfig, tsconfig.json, 'package.json` ....).

So, when I open /root, then any file in root/server/ should be handled as if I would open root/server/ directly. The simplest solution would be to stop searching for settings in parent directories one a .vscode/settings.json file is found.

This is really needed.

+1. Dealbreaker for me.

This is really needed. +1

there have a workaround to nest folders under a vscode workspace. just to create a symbol link to the workspace's folder, like this mklink /d link target

I agree - i think this request is a definite requirement.
You don't always have a project in a single folder - you can have ancillary and sibling folders and not having this feature is a real deal breaker for my just now - thats why i have to use sublime.
Please add it!

On the left hand side you show the folder you are in as a project. This could work if you had it where you can see each folder area (project) open there. You can expand it and collapse it like you do now (but for multiple folder areas).

An awesome editor if only I could switch between two projects. A real Dealbreaker.

Hi all, I recommend the Git Project Manager extension if you do a lot of switching between projects in the meantime. It scans a directory for directories containing a .git folder and allows quick switching to them, I've been using it for a few weeks and it certainly makes it easier.

When I switch projects I either go:

1. ctrl+alt+p
2. Type start of project, eg. "vsc" for vscode
3. enter

Or if I want to open the project in another window I hit ctrl+shift+n beforehand. You can configure the extension to always open in a new window if that's your thing too.

This is a screen shot on how you can easily have multiple projects.

@soljohnston777 the problem is that git integration (or any other kind of VS code config) isn't supported at a folder level.

the problem is that git integration (or any other kind of VS code config) isn't supported at a folder level.

Huh really? Did VSCode repeat the errors eclipse made when it comes to the workspace concept? That would be surprising, knowing that quite a few members of the VSCode team have been part of the core eclipse team....

Did VSCode repeat the errors eclipse made when it comes to the workspace concept

I can't speak to the philosophy of the architects here, but this fact (that config is per-instance and not per folder) is the whole reason for this issue and discussion.

You can use separate VScode windows for projects. Why not implement it like that inside VSCode?(separate window per side project button - just reference it inside). It would save the hassle of coding it inside the program, yet the projects show inside, and make it easy to integrate and develop.

Git can be independently placed for each folder area for multiple projects... I find the git to be confusing with VSCode, so I tend to just do the command line anyways (which seems like you should be able to do that in VSCode).

Having a parent folder housing subfolders which are independent git repositories are really helpfull when they all belong to the same project. Would like to see this available, atleast with an optional configuration flag in settings.

I also like to express my strong interest in having git support for multiple git repos.

+1. This is a main feature that prevents my adoption of VSCode as my main editor.

+1

+1 - especially for people who work with microservice/many-repo codebases, this is key. (Key: not having them all open at once, but switching between them, and having the editor remember which files were open and in which workspaces.)

+1
Our setup is something like core code in on GIT repo, some regional code in another repo, and project specific code in another repo so when you work on a project you need to code from all three (or more) repos. Not being able to have a "project" with it's own specific settings and the ability to add multiple folders from multiple sources it's king of a blocker.

@danechitoaie how do you know that a change you make to your core repo doesn't break someone else relying on it for a different region or project code base? Seems like a dangerous way to work; there should be separate release management using some kind of package management system or the like.

Not arguing against some implementation of workspaces, but a full-blown project system adds a fair amount of complexity.

Agree, it is and they should/could do a lot things much better but... it's out of our "mortal users" control or ability to make decisions...

Understood. I love it when that sort of thing happens.

How about this?

For me a simple switch button like that just not enough. If we need just that simple, open 2 instances (ctrl shift N) then use your OS hotkey to switch between windows/workspaces is pretty the same.
I love to have something that make easier to compare files, projects structure, something help me to quickly do minor changes and build and keep all the diff in the same screen, able to revert the changes for all the projects i working with.

+1

+1

Kind of workaround for macOS Sierra.

One tab per project inside one window by setting Prefer tabs when opening documents to Always in dock settings. But it will affects others apps behavior too..

+1

This is becoming a killer for me. I love the program, but man do I not like one just having one window...

Honestly, I had to stop using Code because as much as I like it, it became too cumbersome switching windows.

If this gets fixed in the future I will try it again, until then this is a show stopper for me and every person I had test it.

+1

+1

Please prefer :+1: reactions on the original issue comment as that helps us with prioritization and doesn't send notifications to everyone listening to the issue for updates.

+1

I am currently using Sublime, and trying out Code. It looks and feels nice, but the single project Git integration is a deal breaker. I have a Hadoop/Oozie project, and so have one repo of code, and another of working notes. In Sublime, I have them both open in the same window, and can commit to the appropriate Git repo for each

so, it'll be good to add

+1 yep, critical in microservice world it's usual to have 3..4 repos open at the same time

Weekly Reminder: Stop posting comments with +1. They are clutter and only serve to annoy people following this issue. Instead, give a thumbs up to the initial issue, which is actually counted.

I know you all meant well. So feel free to delete your +1 comment so it's not taking up space in this important historical record, too!

@jamietre I've tried... hard:

Maybe another alternative is to lock down this issue but keep open until resolved? This way, we know the importance of the issue (I'd say we already got enough +1's for it), but can't add to the clutter/redundancy (e.g. no more commenting allowed).

Although that's a rarely used feature I think, I only came across the lockdown on one public project/repo on Github.

The lockdown could be unlocked when deemed necessary, if ever.

@daluu this is how the /aspnet/announcement repo works; every issue is immediately locked. That being said, GitHub should do something in the UI to at least drive people toward alternatives beyond just "+1" as reactions now exist. 👍

把多窗口这个功能整上把，看两个项目以上的文档时，很有帮助，

interesting approach to the problem. I was a VB/.net programmer for many years, loved the languages and the tools, but have been away for a few years in Hadoop/Spark/Scala/Intellij/Sublime-land. I still listen to DotNetRocks, like to keep up to date with what's going on, and was interested to hear about this Code app. On the positive side, it's a very nice editor, with some nice looking Git features, but that's totally irrelevant unfortunately. Because it doesn't handle Git for multiple projects in the same workspace, as Sublime very elegantly does, then I just can't use it

That happens. What I am most surprised by is the reaction here, first to claim that this isn't a necessary feature, and then most of the discussion now seems to be around "how can we stop people posting +1"

I'll tell you how you do that - you fix a basic problem that was first raised a whole year ago! It's called "listening to feedback". Just because you're not personally affected by a problem, it doesn't mean it doesn't exist. If you don't want a particular group of users to use the app, then fine, but don't give us a feedback mechanism, then dispute our problem and then get annoyed with us for keeping asking for it.

I'm back to using Sublime

The "+ 1" issue can be fixed with the following code: if (post_message == "+1") { add_smiley_reaction(); delete_post_message(); }

Dear GitHub, I'm available for hire.

yeah, this is never going to get fixed, is it. Far easier to mock and ignore "+1" comments rather than actually address the core problem, software being marketed to a particular section of developers that doesn't do what it needs to for them to be productive ...

just read this one "Every direct reply to this comment (=more meta) will result in me blocking the user." - now, that's how to manage feedback! Stick your fingers in your ears and say "can't hear you!"

dear lord

@kryps1 then people will add "+ 1" or "++1" or "1+" or "bump" or "Yes, please. +1". Whatever you would do people will find a way around that. Is not as easy as you think.

Stop with the useless debate of +1's please... Focus on what's needed here, which is multiple projects in the explorer.

For the git problem, it just has to be splitted the same way the explorer is (ie by cwd).

Let's not start a flame war over the +1 stuff. It would definitely be nice if this issue was given priority.

But would like to mention to the community, I assume PRs and contributions are welcome ;-) someone can go patch/fix the code if the core developers don't get to it. I had some of my projects improved upon (with forks) because the user/developer rather do it themselves than wait on me to make improvements that they would like to suggest to me. So anyone that annoyed by this issue and capable/skilled enough, please fix (then submit a PR)? lol

And back to the +1 topic, bumping up issue and adding your opinion is good, but the +1 is a lame way to do it if there's other methods available like the thumbs up feature. Consider a Facebook post, or the original Google+ post, and users/readers go add a +1 comment instead of clicking Like (or one of Facebook's new reactions), or +1 for Google+. Over time that's a long comment thread of lame +1s, where as I reader I might be scrolling to view interesting comments but I end up seeing bunch of +1s. This is what was happening here, I'd prefer not to see/read through these +1s, whether I'm a project developer or just a user (or researching this project for potential use).

On a related note, here's a silly (but good intention) use of a GH issue, thank god, people didn't all go +1 on it though: https://github.com/sinatra/sinatra/issues/920

I assume PRs and contributions are welcome

Not really. See this comment from August: https://github.com/Microsoft/vscode/issues/396#issuecomment-241806158

Apparently this issue is in the Roadmap since at least then, but there has been no progress on it. It would be nice to hear a status update from the VSCode team.

For me, and this is trying to get the topic back on track, multiple project folders is needed.

In Atom, it supports GIT, and the only way I use it is to note which files have changes. I have a Rackspace server that won't allow SSH so manual uploads I go. However, I am able to have multiple project folders in the sidebar, and it makes it so much easier to reference code I've used in a previous project. Or switch gears to another project if I need a breather.

With VSCode, the issue that's preventing me from swtiching, and man do I wanna switch, is that lack of multiple project folders in the side bar.

I mean I guess I could just open the root folder to temporarily resolve it, but if I only need 3/20 folders, and I don't wanna see the loose files, then this should be an easy implementation, right?

Update: The big workbench update coming soon is hot exit (#101), while working on hot exit we've been actively discussing this issue to ensure the design takes multiple folders into consideration.

This issue is currently number 2 in terms of :+1: reactions of all issues (number 1 by a long way tagged workbench), as such this is very likely the next large piece of work for the workbench after hot exit.

On :+1: comments; they only serve to annoy the 80+ people subscribed to the issue. Voting on the issue with a reaction however is one of the most powerful things you can do to influence the project.

Also keep in mind we're a relatively small team and that the cleanliness of the codebase and performance of vscode is very important, so things take time to do right. Particularly for something like this which is a fundamental change to how vscode has been build to date, there's quite a bit of work in this issue.

+1

Indeed that would be a handy feature.

I switched from Atom and really liked it, but i work on two UI applications and another 2 SDK's, but the inability of changing between those projects (or folders) quickly is a important lack, i guess that i should go back to Atom until this got resolved

I'm really looking forward to this feature~~~

I'm a golang develper using vscode, hope this has an implement, thx!

I am trying to switch from Sublime to VScode. And soon I discovered VScode not supporting multiple folders in a "project" concept is really a problem blocking me form doing so.

Really love the other features of this "light weight" editor. Meanwhile I believe supporting multiple folders in a "project" wouldn't make VScode "overweight" or "IDE-like". It would just make it more convenient for developers using other editors to make the transition much less painful.

Hope to have this improvement. Thanks!

Also if the team can add the ability to save project based settings which overrides default settings that will be great. The usecase is if I can have different interpreters for different projects. Similarly having different tab sizes etc will also help. Please let me know if this can already be achieved in some way.

As a developer we are always working on multiple projects and we have side projects of our own. Customizing project settings(workspace settings for vscode) every time I switch project is a big pain.

@bajubullet You should try https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig Not sure if it covers everything that you need, but it's a start.

@danechitoaie thanks for the response. EditorConfig doesn't help though, i can specify properties per filetype but if I can save them in as project settings it will be easier and I don't like having .editorconfig for every project. Also in case of extensions like the python extension which let's us provide the interpreter to be used this will not help because python.pythonPath is not supported through editorconfig. Please let me know if I am missing something here. Any suggestions are most welcome.

I agree, I'm also really looking forward for some kind of project specific settings and being able to open multiple "root" folders. It's the only things I miss from Sublime.

This is being Implemented soon!

So no need to keep adding to this post. If you have other issues create a new thread. Thanks!

This is quite a long thread and I read through maybe a third of it, but just want to voice my support. I just installed VS Code with https://github.com/JuliaEditorSupport/julia-vscode as a possible substitute for Atom/Juno. It's beautiful! 😍

When developing Julia code, however, I feel it is pretty important to be able to open multiple packages in different folders. In principle, I could open the folder above, but that would expose the 100s of Julia packages I have installed. I could also change my LOAD_PATH, but I'd much prefer a VS Code solution.

I sincerely hope to be able to open multiple folders. Thank you for the efforts 👍

Hi everyone, as you may have noticed we are exploring the implementation of this issue during this iteration.

From https://github.com/Microsoft/vscode/issues/17608

Investigate into multi root workspaces across the different components @team

I'm looking to chat to 3-5 of you about your use cases as we think through the implementation details. Please sign up for a 15 minute time slot next Tuesday if you can. I would love to chat.

switching between my api and ui is making me crazy... :-(

@ehartford any reason in particular they don't share a mutual parent?

Yes. Git integration doesn't work if I just open the parent directory.

@ehartford good reason :smile:

@waderyan are you looking for _end user_ use cases only, or _extension developers_ too?

As an _end user_ the multi folder support was useful most of the times for _searching purposes_. I used to create Projects adding different folders from different APIs, just for making searches easier (unified). I would say I don't miss that much today, and doesn't bother me to have multiple VSCode windows today, specially after Switch Window command was added :+1:

As _extension developer_ I have some extensions that are based on _Project Context_, like context.workspaceState, activationEvents/workspaceContains. And also Project Manager, which by the way I already started refactoring the internals to support multi folder. I would love to know how this will affect the extensions

Thanks

To add to what I said above ( https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917 ), I actually do use Git submodules, so when I am working on my own (private) packages, it makes perfect sense to bundle them up, but since Julia is still fairly young (relatively speaking), I often need to do work on other packages alongside my own. I do not feel a compelling reason to add these other packages as submodules (although I could).

Generally, for Julia package development, I am constantly hopping across packages so having multiple project folders would be great :+1:

PS: MS, please pay more attention to Julia ;)

Simplest use case: microservices

Haha. Yes @saada 👍 It was actually microservices that brought us to VS Code. We are using Azure Service Fabric and my partner built the first microservices in .NET and Rust. I'm working on the Julia microservices. My partner is a VS guy and liked VS Code for Rust. He suggested I try VS Code for Julia. Thanks!

@saada definitely on the radar. Can you answer these questions to help me be crisper on the requirements?

1. Do your micro services share a parent folder? Why or why not?
2. Is each microservice separated into its own git repository? Why or why not?

1. Is each microservice separated into its own git repository? Why or why not?

@waderyan one possible reason is that some popular PaaS platforms such as Heroku require each app (microservice) to be in a separate Git repo. Deploy-via-git-push has become a popular strategy.

@waderyan I signed up for a slot tomorrow & looking forward to it - but along the lines of use cases like this, ours is similar.

We are a large organization, we have a private npm registry, and publish our own modules that are shared within the organization. We have a react app with a client codebase that's a big app that consumes some common modules (like utility libs, shared components), and a server codebase that's comprised of several modules as well (express server app, backend data service components consumed by the service layer, and the actual services exposed to the client). Active development involves a minimum of two (the client and services layer) but troubleshooting can easily involve a half-dozen modules.

Even when using public npm modules, it is occasionally useful to have its source code linked directly and open in a separate VS Code instance to troubleshoot a difficult problem, or even a bug in a 3rd party module, but mostly it's our own code.

Each are separate git repos. There's no problem keeping them in my file system under a single root folder (i would anyway). But I need to have a separate instance of VS Code open for each one, and switching back and forth is painful because you can only see the file name - not the name of the application itself. There's no way to easily figure out which application/module/project is open in which window. The file name itself provides very little useful information in discriminating between multilple VS Code instances.

There's another open issue related to allowing the title bar information to be configurable which I have also commented on a lot - and also remains unsolved. If it were possible to have the root folder name flush-left in the title bar, the problem of having multiple projects open would be far less of an issue, because I could at least see which open instance was which within Windows when switching tasks. This seems like it ought to be really trivial to make configurable and would at least alleviate the pain of not being able to open multiple git repos in a single instance a great deal while this gets figured out...

@waderyan

1. My web projects are managed by a single parent folder. It's set up this way for organization, and quick links for my repository folders. I also do this, as it's easy for me to swap into a previous/current project to pull code samples when they are going to be reused. As opposed to opening another window, it's easier to open another tab, and more time efficient in my case.

2. Each web project has their own git integration, however for me personally, I don't require .git to be integrated into my code editor. It's a nice option for me, but not a requirement. They have their own .git integration due to wanting to keep each web project separate in my repo host.

@nickmak @jamietre @pesho thank you for sharing your thoughts. This is helpful and I'm looking forward to chatting with many of you more tomorrow.

@alefragnani I'm focused on the end user scenario. We've approached this issue cautiously because of the impact on extensions. We will tread carefully and communicate any api changes. Ping me on Twitter if you want and we can jump on a call to discuss more.

even notepad++ support multi folders. it's the reason cannot left notepad++.
this day working with javascript needs to open multi projects.

I do embedded software work and there are usually a few folders I'm working out of across the system. For example application code, vendor library, and operating system code.

I would like to add my use case here for multiple folders in the same window.

I am a game developer and, for our current game, we have implemented mod support. Our game has a client, server and master server projects. Whilst editing the mod files it's common to only work in the mod level of the game (instead of what we call the core or native level of the actual game code. e.g. Working only in the Lua files instead of C++ and C# files for server and client respectively). The folders can often be not located within a common parent folder.

In this use case, when only working within the mod files, in the past we have used Sublime's multifolder functionality to create a project view of only the top level mod folders from the Client and Server. This allows us to avoid the native files (C# and C++) and quickly edit Lua files across those two projects that are very much related to each other.

Having multifolder support in VSCode would allow us to do the same and greatly ease our adoption of VSCode (which we love very much).

What came of the call that was held last week? I'm on mac and can't seem to open multiple instances of VSCode, which I thought would be a workaround.

thanks!

I had a call last week with Wade, it's obvious and fair that this wasn't a
early priority, they've built a really good editor, and now hopefully
they're extending it to meet different developer's needs. The Dev team are
listening, I'm looking forward to seeing how they go about it

On Sun, 15 Jan 2017 21:20 nowherenearithaca, notifications@github.com
wrote:

What came of the call that was held last week? I'm on mac and can't seem
to open multiple instances of VSCode, which I thought would be a workaround.

thanks!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

in great request
mark

@nowherenearithaca I had great calls with a number of users and shared what I learned with the rest of the team. We're still figuring out next steps but I would expect we would do something in this area very soon.

@waderyan , sorry for the late response:

Do your micro services share a parent folder? Why or why not?

Yes, for convenience. It makes it easier to find related services when they're under the same directory.

Is each microservice separated into its own git repository? Why or why not?

Yes. They not only have different repos, they also have different linting and debugging configurations. Also, using Cmd+P to switch files between projects is super useful. Global search across related projects, ...

Looking forward to seeing this in action!

One solution would be to create a link to the folder where the files you would like to access are located.
It is not ideal but it can help.

_Example:_

/home/myprojet
/home/mylibs
cd /home/myproject
ln -s /home/mylibs
code /home/myprojet

I have 3 monitors and I want to use VSCode across all three. If I can't open multiple instances then at least support undocking the tabs and dragging them out to other windows (similar to Visual Studio 2015).

Agree.

All other text editors do it. Why didn't microsoft think in something so simple and necessary?

@calloncampbell That feature is in this issue: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring I dont know what I am doing wrong but by using code -n I can open as many editor instances as I want.

If I understand correctly, this will be investigated within the February Iteration Plan as "Initial investigation into implementing 'multi root workspaces', 'multi folder' workspaces" :)

+1...
Isn't this possible with old version of VSCode or was I just using Sublime? forgot...
but very handy.
Now my Mac is littered with 6 windows all over the place...

And no I won't open the root folder of all those 6 folders I have opened, coz the explorer is a vertical scroll and it would take me forever to browse through the files...

@edmundtfy it's possible in sublime. Visual Studio Code never had support for this functionality.

@min20 solution is just perfect !!! multi folder project, it would instead multi-windows managed via buttons

@DeeJaVu considering that... VSCode has these mouseover-tooltip and control+click to go to definition. I downloaded some extensions for Sublime but the mouseover and control+click stuff don't work as well.. any recommendations?

I really miss this after using Sublime for years. Right now I'm working with Intershop (as front-end) with hundreds-thousands files per cardridge. If I have to load a full webshop it's really slow when you want to open CTRL+P to quickly switch to a file or when you have to search.

Also, I simply do not want every folder of a project in my editor. I don't need everything as a front-end developer. Just the folders I need are enough.

Another example: creating a Wordpress site and plugins for it at the same time. Why would I need to include a full Wordpress site? It just slows down your efficiency.

Another problem we have: our front-end framework is split in different git repos'. Having more then 4 windows open is a real pain. And SCSS intellisense is not working then (IE. variables from core > package)

TLDR; Please, make this happen. VScode is unusable for large/huge projects

+1, lets imagine you develop a wordpress or a drupal with several custom modules.

Your project root is the root of your website, but you don't want the full website to be a repo, you just want your several modules or themes as independant repo each.

Very common use case in web development that should be covered, even by the smallest/lightest IDE.

+1

+1, would make me able to edit a project and work on it's submodules seamlessly

+1

Its the only issue stopping us from migrating our entire 32 person dev team to VS.

Micro-service development is just not feasible, its painful.

+1

+1, definitely useful, I'm deciding go to vscode from sublime, but, because of this feature is missing, I think I would still use sublime until one day..

Its a very necessary and basic featured. I can't believed how come developers of this great editor ignored it. It is useless without this feature. This is stopping me to switching to VSCode from Atom.

Please add this feature. After using Sublime and then Atom this is for me a necessary feature of an editor. Of course it's not that easy because of the git integration, but it's something I need within my favourite editor.

+1

+1 urgent need

+1 Like it was said before, to move from Atom to VSCode we really need this feature.

ATTENTION BEFORE COMMENT
*PLEASE !!!! Stop comment with a "+1"

Each of your useless comment distracts more than a hundred people only with this thread !!!
If you want to support this feature - it has emotion in the first message !
If you want to subscribe to updates - for this is the "Subscribe" button to the right of topics
Respect the other members, who are forced to read your "+1", "really needed", etc

For reference, the way Sublime Text (as an example) arranges it's projects is by "including" folder trees, with unique options per "folder" included in your project.

To visualise this, the JSON of a Sublime Text project file looks like this:

{
    "folders":
    [
        {
            "name": "Front-End (web-forms)",
            "path": "source/www/forms",
            "file_exclude_patterns":
            [
                "*.sublime-*",
                ".gitignore"
            ],
            "folder_exclude_patterns":
            [
                "node_modules",
                ".idea",
                "bin",
                "fonts"
            ]
        },
        {
            "name": "CORE C# Server Components",
            "path": "Source/Server",
            "file_exclude_patterns":
            [
                ".gitignore",
                "*.resx",
                "*.designer.cs",
                "*.StyleCop",
                "*.testsettings",
                "*.cache",
                "*.user",
                "*.vsmdi"
            ],
            "folder_exclude_patterns":
            [
                "bin",
                "obj",
                "TestResults",
                "Service References"
            ]
        },
        {
            "name": "DB schemas & utility scripts",
            "path": "Source/Database"
        },
        {
            "name": "Grunt Build source",
            "path": "Build",
            "folder_exclude_patterns":
            [
                "dist",
                "node_modules",
                "TestResults"
            ]
        }
    ],
}

As you can see, each included folder is relative to the project path (in the case of sublime text his is the path of the *.sublime-project file). Also, each folder has a section for excluding file and folder patterns with wildcards. Great for ignoring (as can be seen above) test results, libraries that you shouldn't edit, artwork and loads of other stuff.

This is the last reason I have left for not switching.

It's very useful!

+1
Example: need to check if some functionality is not already implemented in other modules that the app references so that I don't duplicate functionality

Obviously the modules are stored elsewhere in the file path, not in the app itself, and using multiple windows is pain with just one screen, when you just want to quickly access a file and read the code
I'm talking AngularJS apps, which don't need deployment or anything, just a running server.
Why should i bother to dev in another file structure, when i can just open the App folder directly from Tomcat and have my changes take effect in real time.

And no, there is no parent folder, unless you suggest opening the Tomcat server folder as a project (which is like suggesting I open my whole HDD as a project, because I'll be able to open all the files then).

Wow, I uninstalled atom to try out VS, and this feature hasn't been added since 2015.

stoffeastrom opened this issue on 21 Nov 2015

That's depressing. :disappointed:

PS: Opening the master folder, is not exactly a solution as it opens up all unwanted files as well, beating the whole purpose of this ticket.

That's depressing indeed. But then again not as depressing as people still complaining about an amazing, free, opensource editor (which consistently adds a handful of new features _every month_). Nor as depressing as spamming everyone watching this thread with comments about one's depression.

_{(Now I am one of the spammers, I guess :grin:)}

Update: The current plan is to look into this in the March/April iterations.

See https://github.com/Microsoft/vscode/issues/21923 for the March iteration plan:

Investigate into multi-root, multi-folder workspaces #396 @bpasero @Tyriar

+1

To share a real world example that refines the feature description: Example, WordPress Theme/Plugin dev.

In other editors, I set up several folders as "bookmarks", to get to a fairly large and complex file tree a little bit easier to manage. One is to the webroot, which is the root I'd prefer any debug and code completion function look up to start at (the environment). Second is to the actual project, a theme folder or a plugin folder which, in my workflow, is the version control root. Occasionally, I set up additional folders as reference, such as a parent theme, or template theme, or a plugin that I'm integrating with and I need to reference/read frequently.

So the feature set here is, 1. the ability to set the git root and the search root to different locations. 2. A folder bookmarking system that is purely visual to declutter the file tree panel.

For some on the thread, where the git root, and the project root is the same, it seems that learning and using submodules would be enough, and then it's just about 2. to get a nice less cluttered view of a nested folder.

I'm sure that some on the thread are actually asking for literal multi-project support, but I'd assume most are just asking for mainly the simpler folder bookmarking idea.

I'm additionally asking for a way to define one as a project root (search/debug), and another as a git root. (Feel free to ignore my poor naming of things.)

My workaround for this is simply create a parent folder and within create the symbolics links with all the projects that I want.
_e.g._

I have these projects

1. my-app-api
2. my-app-client

I create a folder called _my-app-all_ (the name is irrelevant here) and within, I create two symbolics links pointing to my-app-api and my-app-client then in VSCode I just need to open my-app-all

Steps

1. mkdir my-app-all
2. cd my-app-all
3. ls -s ../my-app-api
4. ls -s ../my-app-client

Notes:
The git integration won't work

@DannyFeliz this should be marked as an answer to this issue and posted up top for everyone to see... I've tested this on Windows too, using the MKLINK command.
Example of usage:

1. Open Command Prompt with Administrator privileges
2. Go to your project folder
   3.[optional] create a links folder
3. use MKLINK /D "link_name" "path to folder you want to reference"

When you open the project in VS code you will see the referenced folder and all the files/folders in it.

Happy coding guys!

This does not enable the Git integration to work.

On Mon, Mar 20, 2017 at 2:42 PM, poparazvandragos notifications@github.com
wrote:

@DannyFeliz https://github.com/DannyFeliz this should be marked as an
answer to this issue and posted up top for everyone to see... I've tested
this on Windows too, using the MKLINK command.
Example of usage:

1. Open Command Prompt with Administrator privileges
2. Go to your project folder
   3.[optional] create a links folder
3. use MKLINK /D "link_name" "path to folder you want to reference"

When you open the project in VS code you will see the referenced folder
and all the files/folders in it.

Happy coding guys!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford I said an answer, not THE answer, as most of us were looking just for this exact thing, displaying several directories in the same VSCode window, that reside in different locations.
Symbolic Links do just that, but when working on Windows this is not the solution which comes to mind.
It had to pass 2 years and for a Linux/OSX developer to come and show us the simplest workaround.
I'm glad I decided to finally drop in my comment on this issue as I've got a workaround for what I wanted
after just 12 days, when I needed it the most.

The issue should not be dropped, as a lot more can be done if the developers choose to step in on the matter.
But for the most of us this is satisfying. I was just suggesting to somehow move this on top, so people don't waste time reading all the other comments, until they reach this comment. Some might just overlook it because of the size of the thread.

I'll just edit this as I see people already jumping on my back because I found out how to achieve what I wanted and tried to make it easier for others to see an alternative even if not perfect. BTW: You can always use the command prompt integrated into VSCode to pull/commit/push files in individual linked folders but why settle for workarounds.

Without Git integration, it's a total nonstarter. I don't consider this an acceptable solution by any means. Looking forward to an actual solution. Best regards.

If it helps -- google appengine nodejs client is structured like this:

https://github.com/GoogleCloudPlatform/google-cloud-node

I'd love to be able to open / debug / work in a solution like this (even if it's one package at a time). I'd love to be able to write Typescript based projects / libs in this style.

Thanks for all the great work!

Love VSCode, but it's crap at handling multiple projects. But I can understand why the feature has been put off, as it makes multiple things like source control more complicated due to nesting etc.

I would happy for a 'project quick switch' feature OR the ability to 'tab' multiple vscode instances in one window.

完全同意 ，请支持同一个窗口中打开多个项目文件夹。这功能很重要。

@replete It's not a perfect solution for your problem. But give Project Manager a try, this is partially helping me right now.

@dariusrosendahl Yep, discovered this morning funnily enough! Does the job for now.

The sidebar has only 5 icons, It wouldn't take much to add a 'Project' sidebar. But it seems vscode product owners are super fussy about how minimal it is. Too minimal IMO as it's now becoming an IDE.

@replete glad to know it's being helpful 😄

In fact, there in an _experimental API_ for creating a so called _Tree Explorer Contribution_ (just like a Symbols panel - https://github.com/Microsoft/vscode/issues/15485). With that, the extension could add an icon to the Activity Bar.

I will add an issue to my extension with your suggestion, thanks 👍

+1

@dmccaffery

I, personally, don't care if this feature ends up in the product or not -- I understand why some folks want it, but I would point out that it does make everything slightly more convoluted.

Then maybe don't dominate the conversation with negative comments against the feature and about how VSC is not an IDE? I think a single response/negative voting is enough, or at worst two, if one needs to clarify a position further.

Besides, the "not an IDE" argument is moot. Other non-IDEs also allow for that.

For instance: when searching using a regex expression -- which workspace am I searching? one? all?

Not that big an issue. Either search all, or have a selector to scope the search to one of the open workspaces. Again, other "non IDEs" (as well as IDEs) already handle this (and other) cases.

I fixed this issue in my own setup by creating a dir for each "workspace" and symlinking to the projects I want to see in that said workspace.

I saw that

Initial investigation into multi-root, multi-folder workspaces #396 @bpasero @Tyriar

is done according to https://github.com/Microsoft/vscode/issues/21923 any updates on this? :)

We (subset of the team) did an initial investigation in the amount of work involved and the challenges we see and the next steps is to discuss the result of that with the team and plan for it. We do our planning for April release during this week so I would expect more fine grained plan items as a result of this work showing up soon.

If I'm not too late to the party here's a nice way this could be implemented.
When you go to "Explorer" we already have two sections. One for opened files and one for the explorer tree of the current opened folder.

Ideally we could just open more folders in same window and they would be added here in its own section that can be expanded to see the explorer tree.

Same thing could be done for Source Control section. One subsection for each folder that is opened in the "explorer". So a 1to1 relation.

This way maybe we can make everyone happy. We have support for opening multiple folders in same window if we want to, and also GIT integration still works and is able to handle each "project root" separately.

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

+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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

@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.

+1

+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.

+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 .

+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.

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

+1

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

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.

+another one

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.

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

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.

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.

@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.

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

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.

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.

+1

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.

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. :)

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.

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.

: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.

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.

NO plan about this feature?

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

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.

@Tyriar @stevencl Thank you guys! :clap:

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.

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

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 😄.

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

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?

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.

@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?

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.

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.

If the "one section per root folder" solution is chosen then I'd like to suggest that the currently visible root folder "sticks" to the top of the sidebar, instead of scrolling up out of view. It would only scroll up once the subsequent root folder reached the top of the sidebar.

On Jun 4, 2017, at 6:47 AM, Peter Petrov notifications@github.com wrote:

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.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Or we can follow Sublime, Atom approach, but change color or somehow show which folder is the root and/or stick it to the top. Of course both approaches are good, but having a lot of opened folders reduces space, because bar with refresh, create a new file, etc. will be visible, that's why it's better to don't load bar, but somehow show which folder is the root. BUT again, this bar is really good, because it's much easier to see opened root folders and you can refresh them and do other things which are included in the bar. We need to see how it looks like with for e.g. 10 folders opened with and without bar.

@stevencl Thank you for posting those recordings! Overall, I'm excited about the direction in which the feature is heading! Thank you for all the time and effort put into it so far. Here is my feedback/thoughts:

• I prefer the first design with the single folder name bar design under "EXPLORER", however, I'm concerned that if all folder names are listed there, it'll very quickly get truncated in order to show the "add file", "add folder", etc., buttons. I think I'd just put the string "Multiple" or something similar when more than one folder is open; otherwise, there's just one folder so put the name of the folder there as is done today (and hide the folder root in the tree).
• The disambiguation of file names by appending the folder name in the tab title in the Editor, IMO, is not necessary unless there are multiple editors open with the same file name. Note that this scenario is not uncommon even with a single folder open. It's quite easy to get multiple files (e.g. .gitignore) with the same name among subfolders within the same root. So this design (appending the parent folder name) should be a separate feature, IMO, and should be implemented. Along with this, I'd love to see a good solution to https://github.com/Microsoft/vscode/issues/15048 because this will make some tab titles even longer. :)
• For search results, I think it's essential that search work across all root folders. Another filter could be added to limit the search to chosen roots. When displaying results, it might be useful to see results per root, so maybe an option to see one long list with root folder names appended, or to see a list separated in sections, one for each root folder.
• I find it strange that you're proposing to add 'workspaces' to the __user settings__. I really expected this to end-up in __workspace settings__. I _think_ you're actually saying that the workspace settings can also contain the new 'workspaces' property, which is good. It's also really good that workspace paths can be relative. It just doesn't seem to be something that belongs at all in the user settings. It's a feature that feels very specific to workspaces. Ah, but now I see why it's also valid in user settings, because it affords me a way to store these workspaces when I want "random" folders on my HDD in one workspace where there's no common root.
• One thing that seems to get lost in the workspaces when they're stored in user settings is the ability to have other project-specific settings attributed to one workspace or another. For example, if I had a workspace where I needed the tab size to be 2 spaces and another where it had to be 3, I wouldn't be able to do that with workspaces in user settings. I'd have to create a folder somewhere, and then put a .vscode folder inside of it, and then define .vscode/settings.json in order to finally define my workspace with the appropriate tab size override. At this point, I'm thinking that creating a new VSCode Project file type that stores all these settings and can be opened as a special file becomes much less cumbersome than having to create this hierarchy of folders to store the workspace settings.json file...

In first design, for additional folders, the path (relative or absolute) in parenthesis can be appended to the name for differentiation. That will be a simple solution I think.

@stevencl thanks for recording the sessions. I really wanted to participate but wasn't available at the time 😢

I liked the proposed SCM interface. Having a summary section and the One section per folder gives me, IMHO, a much easier interface to detect and work with the changes. And I like the idea to have a consistent behavior in the entire UI, so the One section per folder idea should be used in Search tab as well, instead of concatenate the folder name at each result. The same for the Explorer tab.

Using the User Settings to store the _Multi-Folder_ is a bit strange for me, because it _doesn't seems to be a user setting_ :smile:. If the intention is to avoid creating new files and making it easier to transfer/sync projects/workspaces between computers, why don't you just forget about the _user settings_ and make the additionalFolder entry _always_ part of the Workspace Settings. Doing so, when you _Add a Folder_, it will be added only to the Workspace Settings. Then, when opening a folder, you just look for .vscode\settings.json file and a additionalFolders entry in there, to check _if this is a multi-folder_ workspace. _It's similar to the second example that you used, about the two missing git repos_.

SomeFolder.vscodesettings.json

{
    "editor.wordWrap": "off",
    "editor.codeLens": false,
    "editor.renderWhitespace": "all",
    "workbench.colorTheme": "Abyss",

    "additionalFolders": [
        "./express",
        "./express-plugin",
        "~/commons/other-stuff",
        "file:///C://Temp//oldlib"
    ]
}

Also, support _user-data_ locations like ~ and $home, making easier to share projects between different computers/platforms.

I missed only one point: API. How extensions would integrate with that?

Thanks for the efforts. Looking forward for the first insiders releases 👍

Thanks for the feedback! I wanted to follow up on the direction of leveraging a new settings property additionalFolders to implement "Multi Root" because I hear some feedback on this from the comments above.

The main motivation for introducing a setting in the first place is actually to keep things simple and not introduce too many new concepts while still having a solution that is powerful and enables some interesting scenarios. Here are some design decisions and consequences:

Keep it simple
We feel that opening files and folders is at the core of VS Code. Thus we would not want to introduce a new top level concept of "Projects". For example, we would not think a "Open Project" action was needed, but rather think that a project is always a folder and it can optionally have additional folders associated. With this assumption, a setting seems like the natural way of allowing for that. Whenever you open this folder, you open the additional folders with it. Adding and removing folders is a simple gesture and it will update settings directly.

Settings are powerful
Having multi root as a setting enables a lot of interesting scenarios. For example, you are free to put the additionalFolders setting into your workspace and as such share this with other people (by using relative paths - this is shown in the videos).
On top of that, you are also free how you setup projects in the first place: for example, in some cases there is no clear relationship of a master folder to additional folders (e.g. it could be that some of them are not even related to each other). In that case you could just create a "project" folder that just includes a settings.json with the folders it links to:

allMyRandomProjects/ 
  .vscode
    settings.json <- contains additionalFolders setting  

Now when you open allMyRandomProjects it will show you the list of folders based on the settings. You can even include some settings in settings.json that should apply to all the folders shown.

Workspace switching and multi windows
Without a doubt, we need to work on better workspace switching and multi windows support in VS Code. Since we treat a multi-root workspace the same as any other workspace with a folder, improving workspace switching and multi windows support will benefit any user, even those that are not leveraging multi-root workspaces.
We will have to look into better and easier ways of switching between folders and opened windows independent from multi-root.

In my next comment I will provide some feedback on individual comments made.

@borekb search would include options to limit to a specific root folder (or multiple) in the same way you can configure search to include a specific path today already.

@maddouri @TurkeyMan @pesho, @dgileadi @stefcameron it seem clear that some people prefer a single tree and other prefer multiple sections in the explorer. So we might end up with a setting for this, there are pros and cons for both solutions and it should be up to the user which one is better for the scenario.

@borekb how settings apply will change a little bit depending on wether you are in a multi-root setup or not: user settings always apply to all folders opened as before. Workspace settings will be picked up from the main ("master") folder and applied to all files and folders that are associated to it. Now, you can still define settings on any of the additional folders via workspace settings though we might not support all of them. For example a setting like update.channel: none cannot be supported on a per-folder basis. What we will have to do is to identify settings that we can support on a folder level (e.g. files.exclude, all editor settings) and make the necessary changes to enable them. This is one of the major areas of work we have to invest in, especially since extensions can also define settings that we want to support on a per-folder scope.

@BTMorton it seems to me you want easier ways to switch workspaces. This is something we should look into independent from multi-root for any folder transition a user can do.

@stefcameron we will keep the additionalFolders setting open enough to eventually add additional meta data to it. For example I could think of being able to provide a name for such a config so that switching between projects goes by name and not main folder.

One thing that we have not touched on yet in the videos is how extensions can support multi-root folders. Another primary goal with multi-root support (besides "keep it simple") is: do not break extensions

Today, extensions have simple API to get access to the currently opened workspace (workspace.rootPath: string). This property can be null in case no folder is opened.

Now, with the introduction of additionalFolders setting, an extension can still rely on the workspace.rootPath property being set (if a folder is opened), or not (when no folder is opened). Since additionalFolders is actually a setting, an extension is free to read and even write to this setting with the APIs we have today around settings already. There is even an event emitted when this setting changes, allowing for dynamic reaction to the user changing this setting.

Reading this setting allows to make an extension aware of additional folders in the workspace. E.g. the Travis CI extension could chose to show an aggregated status across all folders.

Writing this setting enables some interesting scenarios for extensions: e.g. you could have a project-manager extension that dynamically adds and removes folders to your workspace and as such allows for project transitions within the window, e.g. by showing a list of projects via a picker UI.

At one point we will probably introduce some real new extension API to deal with multi-root folders. Burying this inside a setting for extensions to read/write is a bit odd. But to begin with, extensions can already explore the additionalFolders setting to leverage it if possible. We will also work closely with extension authors to understand their scenarios and how to better support them.

@bpasero Will the concept of additional folders also be added to LSP, or will VS Code simply start one language server per additional folder?

@felixfbecker this is something we still have to invest and explore to find a good solution for language extensions. Once we think about additional APIs for extensions we also need to think about what this means for the LSP.

It is worth mentioning though that today you can already have situations where users open a file from a folder that is not opened as workspace (e.g. File > Open > somefile.xyz). Ideally a language extension can show the same level of language features for such a file even if the folder of that file is not opened.

In the beginning, opening a file from one of the additionalFolders would behave very similar to opening a file that is not in the folder you have opened initially. TypeScript for example can deal well with this case: they just walk up from the currently opened file until a tsconfig.json file is found and then treat this as a project. Features like find references work without issues:

It would be nice if any language extension could work by just going from the currently active file instead of forcing to have an explicit project context.

@bpasero thanks for the comments. So it seems that in the current model, there will always be a "master" folder: even in the allMyRandomProjects example, this is basically the master folder, though mostly empty. This has some subtle implications but I'd need to think about it some more to provide useful feedback.

Overall, I think that VSCode should support monorepo vs. multiple repositories in a pretty similar way, as per the comment above: https://github.com/Microsoft/vscode/issues/396#issuecomment-306040485.

BTW, how do you define "root", exactly? If I open folder A that contains subfolders B and C, how much is it different from defining A as path and B and C as additionalFolders? Is the intention for VSCode to treat those two situations fairly differently or basically the same? (I think it should be be very similar experience.)

@bpasero

In the beginning, opening a file from one of the additionalFolders would behave very similar to opening a file that is not in the folder you have opened initially. TypeScript for example can deal well with this case: they just walk up from the currently opened file until a tsconfig.json file is found and then treat this as a project. Features like find references work without issues:

TypeScript does not use LSP though. In LSP, language servers have a rootUri, and for example PHP will use this rootUri to scan for files that need to be indexed. It doesn't have a file like tsconfig.json that would denote a "project". So if there are files that are not opened through didOpen but also not under rootUri, then these would not get considered for code intelligence, hence my question whether LSP will get extended for this.

Just to clarify, would opening multiple roots create a file ./.vscode/settings.json if it didn't already exist?
As from what I've read here so far it looks like we're saying it would.

I understand why its useful to avoid adding the concept of projects, but perhaps it would be good to make the saving of a workspace optional - even though in this case, 'saving' just means creating a settings file in the root folder.

I think it might surprise a user who hasn't been following this thread if they opened a second folder and it created a settings file. Opening folders is the kind of thing I believe most users expect to be read-only.

Thanks for all the feedback everybody, this is very useful.

@saborrie - good question about the extent to which people would be surprised by the creation of a setting upon adding a folder. We will need to investigate that to see if that is the case (obviously with people who have not been following this thread :-) ).

@borekb - we have talked about the scenario you mentioned (opening a folder that contains one or more subfolders) and we have been leaning towards treating this the same as opening a multi root workspace. The challenge though is in determining when to treat such a situation as multi root and not just a folder that contains other folders.

I'd be interested in what others think about this too.

@borekb you bring up a good point, I would also say that if you open one folder that contains multiple git repositories within, our SCM view should be able to show you the same view as you would get if you set this up explicitly via the additionalFolders property. I think we can start to explore this UI evolution with folders that have additionalFolders setting set and later expand it to more use cases. Another interesting and related scenario is how we chose to present submodules in a repository.

I would also think that eventually we want to support .vscode settings on any folder hierarchy level once we have solved the challenges that come with it.

I would speak less about master-details relationship when talking about multi-root because most of the UX will treat the main folder equal to the additional folders. Master folder is really just the container of the settings for additional folders and will be the main driver for global workspace settings. For backwards compatibility it will also be the one we send to extensions as rootPath.

@felixfbecker does that mean I cannot do a "Find References" or similar language features when opening just one PHP file of my project, I need to open that folder to get these features? I am not deep into PHP, but if there is a concept of cross-file dependencies, I would not be able to navigate to another PHP file from just a single file, I need to open the folder first?

@saborrie we would NOT add a workspace setting by default when you add folders. One of the reasons we decide to put this into user settings is so that a workspace is not becoming "dirty" with the multi-root setup. Putting this setting into the workspace is possible, but you will need to do so manually. It will not happen by default.

@bpasero Ok yes, sticking with the saving into user settings rather than workspace settings would prevent the dirtying of the workspace folders - I'm guessing that it would still save before requiring the user to explicitly perform a save action though yes?

That leaves me with two follow up questions:

1) What would happen when a user opens a workspace with additionalFolders defined in its workspace-settings? Would this become synced into their user-settings? and would it override the entry for that workspace-root if it existed in the user-settings workspace list? Or vice versa?

2) Is putting this list of workspaces into user-settings a better option than initially avoiding storing workspaces in either of these JSON settings files? In the current single-folder system, when a folder is re-opened from the File > Open Recent menu item, the tabs which were open previously are remembered - as far as I can tell this isn't being stored in any user-editable settings file, couldn't the additional paths be stored in the same way, until a user saves them explicitly?

-- Sorry for the English, I used Google Translator --

Well, I went over the layout, (yes - a little difficulty in understanding English). Sorry then...

I did not like the layout presented by @maddouri, mainly due to the problems found in this issue (#25352, #25354). I think it will be more complex even if you have to use the keyboard to access the folders in the displayed model.

I prefer this model, which by the idea I can navigate between the different project folders using the arrow keys and if I need to create a folder / file in the main folder, I can use the menu key on the keyboard, right in the main folder.

And / or with the options of new file, new folder update and Collapse All.

As for the title that appears at the top, I prefer that it focuses on the current file with the folder it is in, or instead of showing all open main folders plus the current file, similar to this image.

And a question: Will Open Editores still exist?

@bpasero

does that mean I cannot do a "Find References" or similar language features when opening just one PHP file of my project, I need to open that folder to get these features? I am not deep into PHP, but if there is a concept of cross-file dependencies, I would not be able to navigate to another PHP file from just a single file, I need to open the folder first?

That is correct, if you just open a single file, you cannot go-to-definition to a file in a different file that is not open, but only to those below the rootUri. That is because in PHP every file can dump symbols in the global namespace, and namespaces are really just name prefixes for classes. There is no restriction on how namespaces and class names need to correspond to directories and file names (only some conventions), and there are no import statements like in TS, only namespace aliases. Loading classes happens at runtime through registered "autoloaders". That means for a language server on go-to-definition, a symbol could be defined in any file. So the language server will index all files in rootUri on startup and then work with the index to answer requests. What does work is if you have a project open, and you create a new unsaved file - you will get intelligence for that, because you got the rootUri and the new file through textDocument/didOpen. But any symbols defined in not-opened files not under rootUri will not be considered.

@saborrie workspace settings override user settings, same as before. A additionalFolders setting inside the workspace always takes precedence. Given the nature of this setting though, you can only override the additionalFolders for the currently opened folder when this setting is specified inside the workspace (this is shown in the videos by having path: "." for the "master").

Having this as UI state stored similarly to e.g. how many tabs are opened was an option that we discussed but we did not find it has lots of advantages over a setting. Some reasons:

• this is not shareable (neither via workspace setting, nor via a settings sync extension)
• this is not something extensions can access today easily (settings API exists, UI state API does not)

Is there a particular reason you would not want this inside settings?

@Tekbr yes, "Open Editors" will work as before

@felixfbecker would the PHP extension able to adopt something like rootUri: string[] easily? Or would you rather want the PHP language server to get started multiple times for each folder opened (e.g. VS Code would multi-plex on the level of opened folders to N language servers?)

@bpasero PHP could work with rootUris: string[] quite easily. Other language servers may not though. Spawning multiple language servers would mean each folder works isolated (no jump-to-definition, find-all-references between them). Maybe an approach would be a new ServerCapability that decides whether VS Code will spawn one or multiple language servers.

I like the concept of the additional folders setting. For me having a single root folder is enough. If I want full development functionality on an associated project I can open a new vscode window.

What I need from the additional folders is just limited functionality. For example I might want a symbol definition from an associated project for use in the root project but not need or want the ability to rename it or find all references for it in the additional folder.

@bpasero I'm just advocating for considering making the creation of a workspace in settings optional (and opt-in). Essentially instead of automatically changing settings when a user adds a folder, start with it just in UI state, and then allowing users to save this to settings in some way. Perhaps also allowing a choice of whether it goes into workspace settings or into user settings.

I'm not completely against storing entirely in settings, I'm just doing my bit to question the decision not to use UI state, just in case it had been overlooked.

@bpasero @saborrie If we go that route, then I would add that when prompted to save to settings, there should be an option to "remember my choice" (to save workspaces to settings, either user settings or project settings). I would be disappointed to open a VSCode window, load a few folders, get it all working the way I want and then either a reboot or crash occurs and I've lost my whole configuration for that combination of folders because the workspace was never saved to disk.

#396 (comment)

@Tekbr yes, "Open Editors" will work as before

Thanks for the reply, @bpasero.

TL;DR: Use a tree view whenever it make sense as opposed to appending the name of the roots to each item.

Few things, I really dislike the way you append the folder to the end, I'd really like it to be an option because I would probably like to have it like thisexpress\.editorconfig and express-plugin\.editorconfig so maybe you can offer the following option: editor.tabName: "${root}\${filename}"

Another thing I would like and you mention it in the video is coloration over roots to match the tabs so 👍 for this.

Search:

In the Search view I'd actually think that you're making a mistake as far as the experience goes, in my mind it should be displayed as a tree, like this:

[-] express
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 
[-] express-plugin
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 

The reasons for this is:

1. You can easily see where are the files regardless to the length of their names.

2. You can collapse the roots you don't want to see.

I think that it also fits more to the kind of design you applied to the Explorer.

Tasks:

For Tasks I'd prefer to have this kind of view:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Few points:

1. In my opinion you shouldn't touch/change the folder names, meaning "express-plugin" should be displayed exactly as it's displayed in the Explorer and not as "Express Plugin".

2. Moving between tasks with the keyboard can also be made in such a way that it ignores selecting the roots so if you move down from express\"Run Tests" in the example the next item that would get selected is express-plugin\Compile as opposed to express-plugin

p.s. Haven't seen the whole video yet but these just things that came to mind.

What if all of the root folders you include in your workspace have the same name?
e.g.

• /dev/project/public/src
• /dev/framework/src
• /dev/some-component/src

You would then have a workspace with:

[+] src\
[+] src\
[+] src\

As per the _sublime_ way of including folders in a workspace, each virtual folder root has:

• Path
• Name (optional) - this is the name of the folder if excluded, but can be displayed as anything
• Exclusion filter for Files/Folders

See note https://github.com/Microsoft/vscode/issues/396#issuecomment-283541760 (above) for example of the metadata associated with this way of doing things.

I would like to know that this feature is still in the development stage ?

@ifzm It is and if you read the latest (May 2017 (version 1.13)) release notes you would know that they are actively working on it.

@eyalsk Sorry, I did not look carefully, this is an exciting feature :D

I'm not crazy about the additionalFolders concept, although I understand the desire to keep things simple.

It seems strange to me that one of a set of folders will store the configuration of the "workspace".

Imagine the following root folders:

• website
• api
• mobile

... which folder should hold the additionalFolders setting? Why?

I prefer the idea of a workspace/project manager, where the settings are stored in a shared/general location. I really don't think that this is complicated from a UX perspective, and the existing workspace terminology could be reused/extended.

Unrelated: I fully agree with @eyalsk's comments regarding nested lists (and tab naming).

@glen-84 in that case you are free to have a fourth folder on disk called "my-mobile-website-project" which has this setting and links to all the other folders.

@bpasero I understand that, but it's really just a hack.

To elaborate:

I'm busy working on the website, and decide that I want to make some changes to the api. If I click Add Folder, it's going to associate the api with the website, such that opening the website in future opens the api as well. I need to understand how this works, and when I do, I have to open a separate instance of VSC, create an appropriately-named empty folder, add both "project" folders to it, and then close off the initial instance.

In contrast, I could simply go Add Folder, and it could (optionally) prompt me for a workspace name to use in future for opening both folders at the same time.

workspaces.json (example)

{
    "workspaces": {
        "My company workspace": {
            "folders": {
                "/path/to/website": {
                    "folder-setting1": "value1"
                },
                "/path/to/api": {
                    "folder-setting1": "value1"
                }
            },
            "settings": {
                "workspace-setting1": 123
            }
        }
    }
}

I just feels more flexible and less awkward to me.

@glen-84 understood. going with your proposed solution makes using VS Code more complex, that is why we chose against such a concept. The main reason is that suddenly there is not only "Open File" and "Open Folder" but also "Open Project". Staying with the primitives we have is the more straightforward approach without introducing new concepts.

That said, all the work we do now to support multiple folders is good work also for scenarios as the one you propose. If we ever want to support your scenario, the steps to get there are much less heavy because the UI is already fit for it. I could also envision that maybe an extension could introduce such a notion of workspaces and we just add the necessary APIs to support this.

Let us first get the UX right without introducing new concepts and then think about other scenarios around multi-folders. There is lots of things to look at first (extensions, settings, SCM UI, etc.).

your proposed solution makes using VS Code more complex

I have to disagree with this. If a user is confused by an optional "Open Project" (or workspace) feature, then they're likely to be confused by many existing features in VSCode. This is not complicated from a user perspective (if anyone reading this disagrees, please say so).

I could also envision that maybe an extension could introduce such a notion of workspaces and we just add the necessary APIs to support this.

The extension already exists, and has been mentioned a few times already. The author even has an open ticket tracking multi-folder support. This extension has 370k+ installs, and a rating of 4.7. Even with a simplistic UI utilizing the command palette, there is little sign of confusion judging by the comments.

Let us first get the UX right without introducing new concepts and then think about other scenarios around multi-folders

That's fair enough. Either way, it's about supporting multiple root folders within the same window – the actual method of managing these folder groups could be tackled at a later stage.

Would you consider creating a public poll to gather user opinions on the subject (I'm aware of the YouTube videos, but I'm referring to this aspect on its own), or has the decision already been made to go with the additionalFolders concept?

I agree with @glen-84. I don't understand the complexity issue. Yes, it can make it more complex, but this is a code editor. I would think it's 95% of programmers who are using it, which could easily understand the idea of projects. There should be little concern about confusing every day people because every day people aren't using it.

While an extension is somewhat of a solution, extensions are also second rate compared to being natively implemented enhancements (i.e. can't add options to the menus, only the command pallette, etc).

@glen-84 the decision has been made to go with additionalFolders setting based on sentiment in the development team, user studies we did (those 2 videos) and feedback we got in this issue.

@pltrant it makes using multi root more complex because you constantly have to think about opening a folder or opening a project. Things like "Open Recent" would suddenly require more attention if the entry picked is a folder or a project, or worse you would even have 2 pickers and have to decide which one to use.

I am not sure how having a setting is more complex. You basically do not have to care about the setting, you just add and remove folders to your setup and the setting is being updated in the background. I would argue that you never look at the value of that setting in most cases.

@glen-84 Regarding your example of a project with 3 folders of same importance, I think which one should contain the additionalFolders settings should be decided on dependency. If API folder is not dependent on other project, when it is opened, it should be opened as a single folder and should not contain any additionaFolders settings. But when you open the mobile folder, I guess it has a dependency on API folder. So, you add the settings in mobile folder for opening API as an additional folder when opened in vscode. Same goes for website. If it's dependent on api, add settings there. If not, no settings needed.

I don't think there will be recursive or cascading additional folder opening. I also like the idea of extensions read other project formats like Visual Studio Solutions and suggest/put additionalFolder settings in place. And you can always open the common parent folder of all.

@stevencl watched both videos.

1. Alternative 2 with the disambiguation seems the most clear. It seems like this could be collapsible (i.e. one of the roots in the tree) which would allow for many projects to be seen at once. If you need a mockup, let me know.

2. Alternative 2 is more efficient from a screen real estate perspective. You won't have the same info (name of the project) repeated at the top -- as in option 1 and then shown in the root of each project.

3. Search Results and Git could behave the same way...as a collapsible tree. The results would be grouped (along w/ status) under their appropriate heading. I guess if you want a navigable summary (as you showed for GIT, that would be an option that could exist across search (how many files you found) and the project area (this could house the action buttons).

So in summary, I'm a fan of the individual collapsible roots w/ the possible addition of the navigable summary. Sort of a combination of Alternative 2 and this example

I hope that whatever you folks choose, that you make the experience similar across the various mechanisms. You say that there were two alternatives, but there are really 4 since GIT and Search were both different. I"m agreeing with whoever made this comment

Re: sharing of the multi-project info. I think it would be useful -- how you have it would be reasonable as a start -- I'd make it just use gulp tasks -- or tasks that VS Code could understand.

Thanks for all of your effort on this.

The implementation of multi-root workspace is being tracked at #28344 and in this June milestone.

@gulshan,

There can be cases where there are no dependencies. For example if I'm working on website and decide to add mobile to work on it at the same time. There are no dependencies between the two, but now website becomes the "parent". If I happened to be working on mobile first, then it would become the parent. It's just a bit arbitrary. The folders could also be for completely unrelated projects.

Regardless, I respect the decision by the VSC developers, even if I don't necessarily agree with it.

Thanks for all the continued comments. As has been mentioned above, we are tracking the work in issue #28344. We will take into account these comments while we continue to work on this, especially while designing the SCM experience. As was discussed in the videos and as has been mentioned above a number of times, we want to achieve consistency throughout the experience.

Regarding the complexity issue that @glen-84, @pltrant and others have brought up, thanks for the detailed suggestions and responses. We understand the feedback and will continue to monitor this as we work on the feature.

The discussion around this has been really helpful and has given us some things to think about for our current design. For example, perhaps we should consider allowing users to choose the 'primary' folder when they add a second folder to a workspace. Maybe we prompt for this when the workspace is closed, maybe it's a setting. Lots of things for us to think about to streamline the experience.

As @bpasero mentions though, we are always very reluctant to add new concepts (such as projects) to VS Code. It's not because we think it would make VS Code unusable, it's more that additional concepts adds to the weight or heft of VS Code, making it feel more complex. Such concepts would be something else that developers have to devote mental resources to.

Furthermore, once something is in VS Code, it's a lot more difficult to take it out (over time people get used to it and depend on it). So we spend a lot of time carefully considering what we add to VS Code and only add something when we are confident that the cost of adding new concepts will be worthwhile. So right now we want to determine how successful a design for multi root that does not add new concepts can be.

Once again, thanks for the incredibly valuable feedback. Without a dialogue like this it would be a lot harder trying to design this experience.

Awesome how thoughtful and responsive all of you on the team are; it's really appreciated!

What probably hasn't been said yet with regards to complexity is that you are adding some anyway. I think these two options are currently discussed:

1. Explicit projects.
2. Something that looks like plain multiple folders but actually isn't – there's an important concept of a primary folder which concerns things like rootUrl for extensions and possibly other things (workspace settings inheritance, for example). I think that typically, VSCode user will need to understand this concept and maybe it would be easier to be clear and upfront about it rather than trying to abstract it away.

I'd actually prefer the third way, really not introducing anything new, just handling things like multiple .git repos and search and tasks and things like that in a transparent way – sort of what the first two thirds of the videos suggested (I very much liked the wireframes). However, then I realized rootUrl needs to be considered for extensions which is probably the main reason why this is complicated.

If it weren't for rootUrl, I'd just start with UI updates as proposed in the wireframes plus local persistence of multi-root workspace, the same way as all other folders are persisted in "Open Recent".

I'd like to repeat that from my point of view, the ideal state is where VSCode works with multiple folders regardless whether they are SCM roots or not (monorepo vs. multiple repos, see above). I believe that the proposed wireframes plus some extra core work like inheriting .vscode settings would be enough for "v1" of multi-root support. "Projects" or "primary + additional folders" could come later, IMO. However, what I'm saying might fall with rootUrl, I'm not sure about that, I just want to convey my general sentiment about this.

It's great that you're trying to solve this difficult problem and keep the simplicity as much as possible!

I have a backend and frontend node project, and have 2 VisualCode editors open, which is a significant resource strain.

I watched both videos and agree with a comment above that these multiple projects need not have anything to do with oneanother. Perhaps one could be a nodejs project while the other is C++.

I did not like the idea of one of the projects becoming the "master" project, with the additional projects added. Each project should be equal and unrelated.

I would have expected to be able to open a folder, and then open another folder (not ADD). The folder will simply be added as in video 1, with the roots just showing up (but show full paths in a tooltip when hovering the root folder). These projects would be completely unrelated. Selecting either one or the other would cause a context switch. It would be as if I was switching between 2 instances of Visual Code, both settings, color schemes, and what not.

The way to persist these multiple projects would be to save this as a new project file, that references the other two projects, but without modifying any of the 2 projects itself. In other words, the 2 projects remain independent, self sufficient and unaware of the 3rd project (settings file) that references them.

Once this 3rd file is saved/created, it should be possible to create settings that override settings from project A and B. Settings not created will again depend on the active project.

When sharing the project, one can share the project file that references the other two. When they are missing from the file system, but contain a reference to their github urls, it should ask the user if it wants to fetch them (by default as a subfolder in root of that master project file, but user may browse for a desired location for each).

Ability to search across multiple projects should be optional, and ability to run and debug multiple projects simultaneously would be very useful, but seems really too complex for a first release, and perhaps such usecase should require running 2 instances anyway. At least for now.

How this should look in the UI is step two, but functionally this is how I would expect it to work. I do not like the idea of modifying either project A to reference B or vice versa, and that is kind of what I understood was the intention. For Agile developent, I'd be just happy if I could work on 2 projects in 1 window isntead of having to run 2 instances, but no more than that for now. Perhaps not even with the 3rd overriding project file, but only with context switching.

Thanks for the continued feedback. There is a definite theme about delaying the persistence of a multi folder workspace until some explicit action from the user (such as save). We'll need to think more about this and investigate further.

I would also suggest the developers take a look at Eclipse IDE on how it
handles this functionality, they figured it out long ago and it works
great.

On Tue, Jun 13, 2017 at 9:11 AM, Steven Clarke notifications@github.com
wrote:

Thanks for the continued feedback. There is a definite theme about
delaying the persistence of a multi folder workspace until some explicit
action from the user (such as save). We'll need to think more about this
and investigate further.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

--
Daniel Sokolowski
Technical Architect

Stantive Technologies Group Inc.
Phone: +1 (613) 634-7410
http://www.stantive.com

Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

Master Project
I am against having a MASTER project. Context switching happens frequently when working with different microservices. This applies to the following points on Linting and SCM.

Persistence of workspace
I think that on the first iteration, we shouldn't have to persist the workspace. I would prefer iterations on one or two releases for this feature before we introduce any settings or persistence layers to minimize any sorts of complex or destructive migrations.

Linting/Settings
Project specific linting should be namespaced to files in the corresponding directories. For example, Project A uses prettier while Project B uses standard. Switching between both contexts should be seamless without linting rules conflicting with each other.

Search
Loved some of the wireframes for this one where search results were across all projects and sorted by project.

_Project A_
file1: matched substring
file2: matched substring
...

_Project B_
file3: matched substring
file4: matched substring

SCM
In this case, I'm leaning more towards showing a breakdown by project with each scm change.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

I feel like these approaches are more transparent and intuitive.

The consensus (based on recent comments and other issues) seems to be against the idea of additionalFolders, at least in the initial release.

While I understand that the decision has already been made, would you consider attempting to implement this feature as a set of APIs, while leaving the persistence for a later iteration? So, APIs for adding/opening folders, and updates to the explorer, search, tasks, and SCM views to support this.

You have talked about how difficult it is to remove something from the product (if a project/workspace concept somehow failed), but the reality is that this applies equally (if not more so) to the additionalFolders concept.

Implementing both additionalFolders and "projects/workspaces" as extensions would allow you to gather usage data without committing to a single model. One of these extensions (or a hybrid solution) could later be integrated into the product.

Have the issues with the environment been fixed on Mac OS? I'm still unable to use Homebrew npm and such without opening VSCode from the command line via code and this will play havoc with multi root support surely?

Yeah, this is a must for me too. I do not understand people's problems with it. It may not be the way one person works, but that doesn't mean another person's preferred workspace management is less valid. I just loathe answers of "Why do you want to do that?" instead of "Let's figure out how to add a feature that every other code editor in the world has."

Back to Atom I guess.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (I get the same issue on both Insiders and regular versions). If I can help debug it, I'm game.

@akutz these guys have put quite a lot of effort into designing a decent multi-root system, they've even put up videos of their design sessions (it was in the latest release notes). It is coming, but they're making sure they get it right :-) (https://code.visualstudio.com/updates/v1_13)

Hi @cliffrowley,

Great to hear. I only recently took another look at VSCode as I've been using Atom forever (and Sublime before that). Recently Atom has been problematic and in a Reddit thread I saw that VSCode was really a great option these days. So I was surprised that it didn't support a basic feature.

Just piling on here -- this really is the only feature keeping me from considering switching out of IntelliJ/WebStorm to VSCode fulltime...mainly because, as a previous poster mentioned, I work with distributed architectures all day and need multiple Git management integrated to my editor (because I'm too lazy 😆 )

I _love_ that y'all are working on this, and I can't wait to see it in action.

I like vscode but this "missing feature" is keeping me away from fully switching from atom to vscode

An early version is already in the Insiders build. Go get it :)

+1 Need this feature

First preview version is very nice guys!
There's already a small issue before I even begin testing properly though...
When I add two "root" folders with the samename from two separate projects, there is nothing to distinguish these folders apart.

e.g. I add /dev/www/myproject/src and then add /dev/libraries/mycomponent/src
All I see is two root folders called src.

> src
> src

I believe we need a way to change the display name of the root folders.
Which would then display:

> My Project (/src)
> Component 1 (/src)

Thoughts?

VSCode shows part of the folder name when you open two files with the same name, that could work with folders too ?

@doublehelix we discussed this recently but didn't have anywhere tracking the issue. I created https://github.com/Microsoft/vscode/issues/29871, thanks 😄

@Tyriar I really find the search functionality confusing to say the least and think that it should display the results similar to how it's displayed in the Explorer as I've said before.

I don't know whether you guys looked into what me and some people said above or whether there are more changes coming but personally I don't like the way you append the name of the root each time as opposed to sort things in a tree-like view when possible.

@eyalsk It's a work in progress, I'll be looking at search results more in July: #29977

The vscode project is based on a folder.
So, you can configure the configuration of each project separately, and you can use the integrated Git directly, or not you can't.

PyCharm :heart: :heart: :heart:

+1

I have to commend you, dear VSCode team.
Finally I am able to ditch Atom since Multi-Root Workspaces landed in the Insiders Builds!
Since two years .gitignore etc. are not respected in Atom when searching in multi-root workspaces and you got it right from the beginning!

Is persistence of workspaces tracked in another issue?

Yesterday the VS Code Team released a new version of VS Code with the Multi Root Workspaces feature 🎉 .

The outcome of this work is what we call a "Minimum Viable Product" (MVP) to enable testing on multiple root folder workspaces.

Actually, is only available in from the Insiders build so you can download it here Download VS Code Insiders

File Explorer

Search

Suppose that every added folder to the workspace is a separate git repository - does the current version of Multi Root Workspaces handle differentiating source control of those repositories?

@Weyzu we are working on adopting SCM for multi root scenarios this milestone. Our initial thinking is that the SCM view needs to become multi-repository aware, which is not necessarily the same as multi-folder aware like in the explorer and search: already when you open a single folder in VS Code you could have multiple repositories within. We think that the SCM view should show these repositories in a good way so that you see outgoing/incoming changes for each repository as well as to being able to commit files from each repository.

The result should provide a better experience for both multi-root scenarios as well as single root scenarios where multiple repositories are contained in one root.

The result should provide a better experience for both multi-root scenarios as well as single root scenarios where multiple repositories are contained in one root.

Excellent approach, you guys rock!

@bpasero awesome! I'd definitely be interested to see your guys' take on it. IntelliJ/WebStorm has something similar where it auto detects Git roots and lines them up for you appropriately in the bottom right, and I've personally loved using it.

Were you guys thinking something along those lines or something a little more elaborate?

We are still sorting out the UX for this and will keep you posted about the results.

Couldn't a virtual file system root work here? It would effectively act as if the VFS root were the parent dir for several, disparate paths.

I wanted to give an update on our multi-root work because today is the first day where our revised multi-root UX has hit insider release and many of you that got used to the "old" behaviour might be confused what is going on.

Flaws of the old solution
The old solution for multi root would introduce a new setting workspace (into the global settings.json) that allows to add additional folders to a single root folder. The setting looked like this in case you have not noticed:

{
  "path to folder": [
      "additionalFolder1",
      "additionalFolder2"
   ]
}

We call this solution "master" folder with additional folders ("detail").

This was the most straightforward solution without introducing a lot of new concepts but has also flaws:

• you could never open the master folder as single folder again because the setting persisted
• you could not remove the master folder from the explorer
• some settings from the master folder applied to all other folders
• your settings get polluted with multi-root configuration stuff
• it is hard to allow to open a couple of folders at the same time (e.g. when you open 3, which master folder should we take?)

Our Solution
We think that a more explicit workspace concept is needed for multi root scenarios and as such in todays insider you will see some new UI popping up:

The idea is that multi-root workspaces require an explicit action to be created. In the same way that you can be in an empty workspace (no folder opened, purple status bar) or in a single-folder workspace (light-blue status bar) you can also be in a multi-root workspace (dark-blue status bar). This third way of opening a workspace in VS Code allows to have as many folders as you like. These workspaces can be saved into a file (e.g. myWorkspace.code) and also include workspace settings. You are not forced to save them though, as long as you do not want to save them, they will show up as "Untitled Workspaces".

To open a workspace you can either open the saved workspace file or pick from the recently opened list:

This is all very young code and very young UX, so expect some changes over the next weeks. We know there are still some things to sort out (e.g. how can we make the transition from single-folder to multi-folder smoother).

A couple of changes that were already made today that will hit tomorrows insider release based on feedback:

• rename .code to .code-workspace as extension for workspaces
• have a unified list of folders and workspaces (e.g. in File > Open Recent) instead of distinguishing between folders and workspaces

Stay tuned for more to come 👍

On top of this, we now have one .vscode folder per project folder containing the file settings.json. This file can contain the following:

// Place your settings in this file to overwrite default and user settings.
{
      "editor.wordWrap": "on",
      "files.autoSave": "onFocusChange",
       "editor.fontSize": 15
}

The problem here is, that when we want to work with multiple users (different RDP session) on the server on the same project folders, we share the same settings. This might not be the intended behavior. I might like my font size to be bigger than my colleague's.

So in my opinion, you should also take into account that different users might be working on the same folders but with differente settings in settings.json.

@DarkLite1 you bring up a good point. In our settings design for multi-root we try to identify settings that we can support per-folder and settings which we cannot support. We typically say that settings which target the editor or a specific resource can be supported per folder because it is clear from which folder the editor was opened. Other settings that will not be supported are more around workbench customization (e.g. showing the statusbar or not).

Your example is about the editor.fontSize setting which we actually support per folder even in a multi root workspace. I think it could be a valid scenario that a user wants to have a larger font size for a folder that contains lots of markdown documentation (even a different font maybe?). So I would think that we should not prevent from respecting this setting per folder also in a multi root environment.

If you want to keep editor.fontSize as a personal workspace setting, then I think it should not get checked into the repository.

With the new workspaces concept you can do the following:

• File > Workspaces > New Workspace
• Pick your folder
• Open workspace settings
• Change editor.fontSize: 15

From then on your workspace will carry this setting, but you are not forcing it to anyone else.

From UX perspective, it would be convenient if I can drag & drop folders into a VS Code window without explicitly having to create a workspace first (it's something I do all the time in Sublime). I invariably work on multiple projects at the same time, and depending on what I'm working on it will be a different (overlapping) set of projects every day.

Workspaces would introduce a concept that is not native to my way of working, and I'd have to keep track of different workspace configurations (as I understand it) which sounds like it will create some configuration clutter in my project folders.

Additionally, I think I speak for many users if I'd argue that things like search, configuration are global by default (apply to all open folders)- though it would be nice if I would have the option to search locally in a folder (I'd always found this tricky in Sublime).

@SanderMertens You might have missed this but @bpasero wrote;

These workspaces can be saved into a file (e.g. myWorkspace.code) and also include workspace settings. You are not forced to save them though, as long as you do not want to save them, they will show up as "Untitled Workspaces".

Now, I'm not sure whether you would have the ability to drag and drop folders but from what I'm getting people would have the ability to open arbitrary folders without making a workspace.

I can't wait for this feature to be included in the stable build.

Yay! 😄

Currently you cannot drag a folder into the explorer to add it, but this is on our backlog. The complication with this interaction is that we do not know the intent of the user: to open the folder in the window or to add it to the workspace?

The transition from 1 folder to many folders currently is a more explicit step compared to what other editors do (you need to go via File > Workspaces > Save Workspace and pick the folders you want). There is a couple of reasons why we want to go with the current behaviour for now until multi root stabilises. The main reason is that multi-root is a major change for all our extensions. While the explorer works and you can search through all folders, most extensions will not work correctly until the new multi root API is adopted. As such, we do not want to make it too easy in the beginning to enter multi-root by accident. It is an explicit user gesture to enter multi root workspaces and in that mode we might want to draw attention to the fact that some extensions are not working yet.

Another reason is workspace settings: Imagine this flow:

• you start with 1 folder which has workspace settings
• you add a second folder (assume this works without context switch and window reload)
• you open workspace settings
  => workspace settings in multi root are now stored in some location outside of the folders because you can have multiple
  => we probably need to ask the user if the user wants to migrate the workspace settings to that new location

So, no matter what, entering multi-root is not a lightweight operation currently. We might revisit this when the dust settles and multi-root is widely adopted, but for now we think this model is better and avoids frustration.

@bpasero I think that by default once you drag a folder into the explorer it shouldn't save it automatically to the workspace even though one may exists and this should be an explicit action where the user click on the folder(s) he/she dragged and then add it explicitly to the workspace and if you have few unrelated folders, it might be sensible to provide yet another action to save all of them at once.

It all depends on the use cases one wants to cover. I've found from experience that KISS is always the best approach. Introducing Workspaces sounds great as a feature but what is the real benefit and what are the disadvantages?

One disadvantage that comes to mind when introducing and using Workspaces is that it needs to store it's data (settings) somewhere and it requires user maintenance/awareness.

Suppose the only goal is to give users the ability to work with multiple folders in one VS Code session. Nothing less, nothing more.

Most common use case:
There's no Workspaces concept. The user just opens an extra folder, or as many as he wants, and they open in the view on the left just like a single folder does. He expects his settings to be the same everywhere. regardless where his files are located. And he doesn't want any extra clutter of VS Code config files in between his project files as stated by @SanderMertens , me and probably others out there too.

Challenges/Problems/Questions:

• Why are there so may different setting files? User settings, Workspace settings? It should IMHO all be stored in one and the same location. By preference in the user his personal folder/profile, so each user on the system can have his own settings. Extra bonus. they don't clutter the project files and multiple users can do their own thing. Clear the profile? Great! Clean slate for VS Code too.

I think Workspaces are a bit over-engineering things if you want:
Speed, simplicity and an editor that just works., no over-complicating things or understanding extra concepts. If users from Sublime or other editors don't use this concept in their workflow, that should be an indication of overthinking things. Or it could mean something really awesome is invented that other editors will implement too, but I have my doubts.

I'm sorry if this sounds as rant, that's absolutely not my intention. But I believe we can do better with regards to multi root/folder access.

@DarkLite1 thanks for taking the time to provide feedback on our new strategy for workspaces.

I agree with all of your points and want a simple solution too. Workspaces as a concept is our first step towards a multi-root solution that works with our existing patterns (workspace settings, extensions etc.). Since this is the first step, expect some rougher edges (e.g. transitioning from 1 to N folders is not as lightweight as it could be). Our goal is to make this transition smooth and not make it any more complex than it needs to be in the future. And we also do not want to force a user to manage these workspaces (that is why we have "Untitled Workspaces" that live as long as the window is open and will go away once you close that window).

There are a couple of things around multi-root workspaces to keep in mind that maybe are not so obvious. I hope the following detailed explanation helps to understand our design process:

Workspace Settings
We do support having settings inside a workspace folder (.vscode folder). As much as some users might not like these kind of settings that end up in .gitignore files or the repository, there are many that rely on this functionality. We cannot simply stop supporting settings that live within folders because users rely on them. Now, for multi-root scenarios it is clear that we have to find a new place for workspace settings. We came up with the concept of a workspace file that contains these settings. As long as the workspace is not saved anywhere, it resides in a folder that has other VS Code specific data contained and when you save the file, the settings will be within that file.

Now imagine you start with 1 folder in VS Code that has workspace settings defined and you want to add a second folder. What should we do now? Ignore the workspace settings of the first folder? Ask the user to migrate the settings? We decided to make this an explicit context switch to make it clear that opening a workspace carries its own workspace settings in a different location.

And now imagine you went from 1 folder to 2 folders and we moved workspace settings to some other place. Imagine you make changes to these workspace settings. Now you want to go back from 2 folders to 1, would you expect to migrate the workspace settings back into the folder?

Another example: You transition from 1 to 2 folders and configure workspace settings. Now you close the window. I think you would get mad at us if you could not get back to this workspace in some way because you carefully configured settings for this workspace. So even though you do not like the concept of a workspace, once you configure settings for it I think you want that workspace to live on.

I hope these examples make it a little bit easier to understand why KISS is not as easy for us as one might think.

Extensions
All of our extensions always worked against an API that provides a single workspace path because up until now we did not support multi-root workspaces. As a user you might think that switching from 1 folder to 2 folders is a very simply and lightweight operation but for extensions it can mean a lot of things: Language extensions that so far assumed there is just one folder suddenly have to be aware of multiple folders. And on top of that, these folders can come and go very dynamically at any time.

Introducing a real workspace concept gives us some more room and time to breadth and help extensions adopt this concept. We could for example disable extensions that have not yet adopted multi-root workspaces to prevent weird things from happening (e.g. a language extension only works on the one folder and reports wrong errors on the other).

Let's try to stabilise on multi-root support with these new workspaces first and then revisit how lightweight we can make the transitions. Once we have extensions on-board and figured out our settings story, I think we can make the flip to a more lightweight experience.

PS: since you make a reference to other editors with regards to their multi-root support, I just wanted to point out that these editors also come with a workspace or project concept that you can save to a file and share with others. Typically you are not seeing these concepts because going from 1 to N folders is a very lightweight operation. I would argue though that people that rely on this feature start to move to saved workspaces/projects as a way to manage work. For example, unless you save workspace/project and close the window, all this information is lost.

@bpasero thank you for getting back to me and for the detailed explanation, I really appreciate that.

As I'm not fully acquainted with Sublime I took the liberty to check on how they handles this. And you are correct, they use Workspaces too and even Project files. The only thing that bothers me a bit is that it puts VS Code files in between my project. But as you mentioned, if others rely on this, it has to be taken into account that this might just be what is best. I'm only wondering why these setting files are not user specific? I can imagine a colleague opening up VS Code on the same folder structure, but wanting to have his own settings.

If Workspaces are the way forward, and it seems they are, it would be logical upon opening the app that it will reload the last used settings. Even if this is an unsaved Workspace. It makes life a bit simpler I guess.

Why did I chose for VS Code? Because it's cross platform, as I use Linux at home and Windows at work, this could really become my default editor! As an extra bonus, I am a PowerShell developer and there is an extension for it too. So two big wins there! On top of that, for the Java course I'm following, Red Hat is making an extension also for VS Code. So once you get to know VS Code better, with its shortcuts and all, you'll benefit across the board.

The app and its extensions are still a bit in beta or even alpha state at some points, but still, great work guys! Really appreciate the efforts and seeing the progress in the Insider builds every day. Keep up the great work and have a nice weekend.

Thanks for that explanation @bpasero, I think I understand better now what the complexity is.

One approach could be to conceptually treat any set of projects with the same configuration as a workspace. In addition to that, you could refrain from adding a .vscode folder as long as the project does not diverge from the default config. That should:
1) get rid of most clutter in projects
2) prevent most config clashes when adding projects (in the simple case, there will be no config)

I think the explicit workspace concept as discussed is a good solution to the mentioned problem. With these two simple rules I minimize the usecases where people run into this problem.

For me, looking at the comments in the thread, and my use-cases, I see _Multi-folder_ and _Workspaces_ as two different concepts, and maybe it should be treated separately as well.

It shouldn't force to _create a workspace_ just to add another folder to the current window. It should just add the new folder in the tree, and leave the newly created workspace as an _internal info_. If the user decides to save the workspace, then the workspace is really created. And even if I don't save the workspace, while reopening the top-folder, it would _remember_ my temporary workspace_ and open the other folders as well, just like it remembers the opened files when you open a folder today. BTW, I wonder how I could open multi-folder in command-line.

For my use-cases, multi-folder is just a way to see more than one folder at a time in the same window, not a _Project Group/Solution_ approach. So, a simpler solution would fit. But I understand how others need a _Workspace_, with its own settings and so :thumbsup:.

The thing that bothers me most about this new Workspaces concept (compared to the first iteration using the User Settings) is the same thing that bothered me when I was using Sublime Text. The fact that you _can_ save the .code-workspace files _anywhere_, and now I have to manage a common place to store them. It would be much simpler, IMHO that it would fit automatically, in one of this two places:

• inside user-data-dir folder, like User Settings and Keybindings
• inside the _Top Folder_

Just to be clear, I understand the more complex workspace concept that other users need. I just wanted a simpler approach for a simpler multi-folder concept.

I like this option, add this option.

Because the folder inside is not very impressive.

or add the ability to change this option.

I like the Workspace idea! Any ideas on when this is going to be ready?

Is it expected at this point that the git information in the bottom left corner does not accurately reflect the git branch of whatever repo the currently focused file is in? I didn't see anything about "multiple git roots" in the v1_15 release notes.

I've been using this feature now with the Insider build for a few days and I must say it's everything I've wanted it to be. Very clean user experience and I can't wait till it's in the main build so I can convert my whole team to this.

When working with NodeJS and having multiple NPM modules open at a time the way it puts everything together into one window is a huge time saver.

Huge props to the team!

Why does this feature show up in my release notes with a gif and an explanation, but isn't available in the actual editor?!

@ShashankaNataraj that is on insiders build not on original build. If you see doc carefully it will be mentioned as only for insider builds

Our roadmap for ongoing multi root work is captured in https://github.com/Microsoft/vscode/issues/28344 and will continue through August, September and probably also October.

We will keep this feature available only in insiders until:

• we can provide a proper multi-root enabled SCM, debug and tasks experience
• we adopted multi-root APIs and functionality for the extensions that we ship with and that we actively contribute to (e.g. Go)
• extension authors had enough time (e.g. 1 milestone) to adopt the new multi root APIs

Please understand that we want to avoid shipping this feature to stable and having a broken extensions experience because we rushed this feature in too soon.

Thanks for being professional guys, great job!

@bpasero I am a bit worrying about extension authors that they will update plugins at time. Do they receive some special upcoming breaking change emails?

Thanks

@FelikZ please look at our roadmap (https://github.com/Microsoft/vscode/issues/28344). For the September release we plan to adopt the extensions that we ship in VS Code and while we are working on that we add the necessary APIs and utilities needed to do so.

During September this is the plan:

Today's insider update comes with some changes to the .code-workspace file that I wanted to summarise here. Existing workspaces with the previous format will automatically be migrated to the new format.

The old format looked like this:

{
    "id": "1500007676869",
    "folders": [
        "file:///Users/bpasero/Development/Microsoft/monaco",
        "file:///Users/bpasero/Development/Microsoft/vscode-distro",
        "file:///Users/bpasero/Development/Microsoft/vscode-docs",
        "file:///Users/bpasero/Development/Microsoft/vscode-extension-sdk"
    ]
}

And the new format ist:

{
    "folders": [
        { "path": "/Users/bpasero/Development/Microsoft/monaco" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-distro" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-docs" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-extension-sdk" }
    ]
}

Workspace ID
The workspace ID is used to associate a couple of things with the workspace:

• all UI state (e.g. opened files)
• all dirty file state (aka hot-exit)
• extensions state (if any)

We decided to remove the id property from the workspace file and instead compute the id automatically based on the absolute file path of the workspace file on disk. This has a couple of advantages and disadvantages but in the end we think the advantages make this a better solution:

• it was weird that you could edit the id in the file simply by typing another value
• it was not very clear how to treat the id when sharing the workspace file with others (should the id be changed? should the id be a uuid?)
• it was not possible to copy a workspace file and open it in a separate window, you had to change the id first in the copied file
• as a consequence, the "Save Workspace As" action would have to ask the user if the copy should have a different id or not

One disadvantage of this approach is that once you move or rename a workspace file, the associated state will be lost. Dirty files ("hot-exit") will still reopen after a restart, but they will open in an empty window and no longer be associated with the workspace window. We still think that we can improve this behaviour, though it is behaving consistent with what happens today when you rename a folder with associated UI state and dirty files.

Folders
We decided to revisit the format of the folders property.

• we no longer require you to use resource URIs, but just file paths to make editing easier
• we changed the entries of the folders property to be objects so that we can associate metadata to the entries as needed (e.g. each folder could have an extra name property)

Finally, support for relative paths has landed as well. You can enter a relative file path and it will be resolved against the parent folder of the workspace file. Note that due to bug https://github.com/Microsoft/vscode/issues/33188 we are currently rewriting relative paths to absolute paths when making changes to the workspace file.

@bpasero it's awesome. When the extra name property will work? At this time I have two folders with the same name in my workspace and it's awful.

@DaniloPolani see https://github.com/Microsoft/vscode/issues/29871

An update to the handling of relative paths: Starting with todays insider build we will write paths to the workspace file as relative path if the location of the workspace file is a parent of the target. In other words, paths will now always be relative unless we would have to use "../" notation to express the path.

Since untitled workspaces always live in the data directory of VS Code, the paths in there will always be absolute. But once you save an untitled workspace to a location, we will rewrite the paths if possible.

If you are curious about the changes around multi root workspaces that went in during this sprint, check the updated release notes.

+1

+1

@bpasero IMHO, the way UI states are handled (weather it's using an ID string in the .code-workspace file, or using the file path as the ID instead) is not adequate.
Renaming a .code-workspace file, or any of its parent folders, or moving it around, and losing the UI state is in my opinion totally unintuitive. I think people unaware of how that works under the hood would have absolutely no clue about the reason they lost their previous UI state and how to get it back.
That should not be tied to the absolute path of the files in the file system at all!

This applies to the way UI state relates to folder path currently in the stable release as well. I was very confused about that at first, until I did some googling.

IMO In case we're dealing with just one folder, UI state should be saved inside the .vscode folder. If we're dealing with a multi-root workspace, UI state should be saved as a separate file in the same folder as the .code-workspace file using appropriate naming conventions (or maybe inside that file itself, although mixing settings and state might not be a good idea).

If correctly implemented, this would allow users to have complete access to UI states, attach new UI states to a given workspace (multi-root or not), etc.
I'd love to be able to sync UI state between different computers, say working in the office, then going home, grabbing a laptop or whatever and continuing exactly where I left off.
Having several UI states attached to a workspace and easily switch between them (menu/keybinding/command/etc) when working on different features would be awesome as well. Perhaps different .code-uistate files inside .vscode listed automatically, or many .code-uistate files prefixed according to the main .code-workspace, or listed in an array.

I'm thinking about this as an extension of how projects and workspaces work on Sublime Text. Same functionality, different design. In this case a VS Code workspace would be similar to a Sublime project, and the different VS Code UI states would be similar to Sublime workspaces.

Regarding this issues:

it was weird that you could edit the id in the file simply by typing another value

Yes, totally. Removing the ID from there was the right choice.

it was not very clear how to treat the id when sharing the workspace file with others (should the id be changed? should the id be a uuid?)

Well, if we've got myproject.code-workspace and myproject.code-uistate then it's up to the user to decide whether to share their UI State or not. No more thinking what that ID means, how it's generated, if it needs to be a UUID to avoid conflicts when sharing, etc.
Want to share folder setup and settings? Send myproject.code-workspace, no need to worry.
Want to share everything? Send both files.

it was not possible to copy a workspace file and open it in a separate window, you had to change the id first in the copied file

If you want to start with a fresh UI state with the same folder setup and settings just duplicate your .code-workspace file.

as a consequence, the "Save Workspace As" action would have to ask the user if the copy should have a different id or not

That was tricky since the user didn't know what that ID was. Perhaps it'd be more straightforward to have two options "Clone Workspace with Current State" and "New Blank Workspace". But that's UX and you'd have to do an analysis about that.

Agreed with Franc, keep all project configuration files inside the settings
folder in the projects, take a look at Eclipse IDE which has the right
approach. It has the concept of project and workspace settings with
project overwriting defaults in workspace. Workspace is just a folder with
folders representing projects. So have .vscode folder in the workspace
folder, and each project have it's own .vscode folder. And please don't
just down vote this for mentioning Eclipse IDE.

On Mon, Sep 18, 2017 at 8:52 PM, Franco Gallardo Grazio <
[email protected]> wrote:

@bpasero https://github.com/bpasero IMHO, the way UI states are handled
(weather it's using an ID string in the .code-workspace file, or using
the file path as the ID instead) is not adequate.
Renaming a .code-workspace file, or any of its parent folders, or moving
it around, and losing the UI state is in my opinion totally unintuitive. I
think people unaware of how that works under the hood would have absolutely
no clue about the reason they lost their previous UI state and how to get
it back.
That should not be tied to the absolute path of the files in the file
system at all!

This applies to the way UI state relates to folder path currently in the
stable release as well. I was very confused about that at first, until I
did some googling.

IMO In case we're dealing with just one folder, UI state should be saved
inside the .vscode folder. If we're dealing with a multi-root workspace,
UI state should be saved as a separate file in the same folder as the
.code-workspace file using appropriate naming conventions (or maybe
inside that file itself, although mixing settings and state might not be a
good idea).

If correctly implemented, this would allow users to have complete access
to UI states, attach new UI states to a given workspace (multi-root or
not), etc.
I'd love to be able to sync UI state between different computers, say
working in the office, then going home, grabbing a laptop or whatever and
continuing exactly where I left off.
Having several UI states attached to a workspace and easily switch between
them (menu/keybinding/command/etc) when working on different features would
be awesome as well. Perhaps different .code-uistate files inside .vscode
listed automatically, or many .code-uistate files prefixed according to
the main .code-workspace, or listed in an array.

I'm thinking about this as an extension of how projects and workspaces
work on Sublime Text. Same functionality, different design. In this case a
VS Code workspace would be similar to a Sublime project, and the different
VS Code UI states would be similar to Sublime workspaces.

Regarding this issues:

it was weird that you could edit the id in the file simply by typing
another value

Yes, totally. Removing the ID from there was the right choice.

it was not very clear how to treat the id when sharing the workspace file
with others (should the id be changed? should the id be a uuid?)

Well, if we've got myproject.code-workspace and myproject.code-uistate
then it's up to the user to decide whether to share their UI State or not.
No more thinking what that ID means, how it's generated, if it needs to be
a UUID to avoid conflicts when sharing, etc.
Want to share folder setup and settings? Send myproject.code-workspace,
no need to worry.
Want to share everything? Send both files.

it was not possible to copy a workspace file and open it in a separate
window, you had to change the id first in the copied file

If you want to start with a fresh UI state with the same folder setup and
settings just duplicate your .code-workspace file.

as a consequence, the "Save Workspace As" action would have to ask the
user if the copy should have a different id or not

That was tricky since the user didn't know what that ID was. Perhaps it'd
be more straightforward to have two options "Clone Workspace with Current
State" and "New Blank Workspace". But that's UX and you'd have to do an
analysis about that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

--
Daniel Sokolowski
Technical Architect

Stantive Technologies Group Inc.
Phone: +1 (613) 634-7410
http://www.stantive.com

Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

@danielsokolowski I understand the notion of a project overwriting a workspace for settings. In vscode you have general settings, user settings (over writing general), and workspace settings (over writing user or general). Each project already has the opportunity to have its own .vscode folder (workspace settings live in it). Are you suggesting an additional folder that would nest projects just to share settings information? That would seem similar to a "solution" file/folder in visual studio terms.

@fgallardograzio Having a project configuration intermingled with settings in the same file will force coupling. The ui stuff sounds a lot better as another feature separate from this issue ticket. Now that the Insiders build has some nice layout of the extra roots in the file, maybe an extension can fill in the gap for the ui part. Thank you. Good day.

@Yemi, yes, so Elcipse allows me to open different workspaces which are
simply folders that contain various sub-folders to represent projects. I
personally use two workspaces, one for developing Eclipse IDE and one for
all my work related projects. The main take away is that settings are just
human readable files stored in their respective settings folders - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
this is very logical to me.

A comment/tip worth mentioning for any IDE, in situations where you have
standalone projects, say workspace/your-awesome-library that you wish to
include as part of another project say
workspace/my-wiget/libraries/your-awesome-library one can use junctions
or hardlinking depending the OS - I find this cleaner than git/hg subrepos
concepts.

On Tue, Sep 19, 2017 at 10:33 AM, Yemi Bedu @ P&R notifications@github.com
wrote:

@danielsokolowski https://github.com/danielsokolowski I understand the
notion of a project overwriting a workspace for settings. In vscode you
have general settings, user settings (over writing general), and workspace
settings (over writing user or general). Each project already has the
opportunity to have its own .vscode folder (workspace settings live in it).
Are you suggesting an additional folder that would nest projects just to
share settings information? That would seem similar to a "solution"
file/folder in visual studio terms.

@fgallardograzio https://github.com/fgallardograzio Having a project
configuration intermingled with settings in the same file will force
coupling. The ui stuff sounds a lot better as another feature separate from
this issue ticket. Now that the Insiders build has some nice layout of the
extra roots in the file, maybe an extension can fill in the gap for the ui
part. Thank you. Good day.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

--
Daniel Sokolowski
Technical Architect

Stantive Technologies Group Inc.
Phone: +1 (613) 634-7410
http://www.stantive.com

Notice of Confidentiality:
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review re-transmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error please contact the sender immediately by return electronic
transmission and then immediately delete this transmission including all
attachments without copying distributing or disclosing same.

Is this feature still not added?

This is very important for me. I am working on a project that is composed of 2 separate repositories: the web frontend, and the api. It would be nice if I could open both of these folders in a single "project".

Sure, I could solve this by cloning the 2 repos into a single folder and opening that folder but this doesn't work for every case. Especially if you have multiple projects that depend on a single repository (i.e. share the same API).

This feature would also be useful for those who use code as documentation.

@JamesTheHacker for a while use vscode-insiders which support multiple projects at same time. And you can suggest features depending on what you feel with the insider version to make it better

When this ships, VSCode version should probably bump to 2.0. Just saying :)

Quick question regarding this feature:

This feature supports adding multiple folders with repositories to an existing workspace. Would it also support a mono-repo configuration, whereby I want to open multiple projects in a mono-repo, but since they are in one repo, they don't have a git repo of their own. So from a project point of view, they don't have a .git folder - one of the ancestor folders has them.

You might ask why not open the mono-repo folder as one big folder and just work in there? There are two answers:

1. (less interesting for me) there are too many projects in the mono-repo, and I'm interested only in some of them.
2. Many plugins assume that a project contains only one... project. For example, only one npm package. So they look for things in the _root_ of the project. Examples: the npm plugin for VSCode, the mocha plugin for vscode, and lots of functionality in VSCode itself - for example, I can't specify a path in the launch.json that is relative to the current file, i.e. "the node_modules folder that is the nearest ancestor of the current file".

After this contextual explanation, my question is simple - would this feature support projects who's .git folder is an ancestor of their root? If so, then it would be possible to use this feature in a mono-repo.

@borekb Yeah. I don't know how people at Microsoft manage their versions, but i think it's a massive enough feature for a major

After this contextual explanation, my question is simple - would this feature support projects who's .git folder is an ancestor of their root? If so, then it would be possible to use this feature in a mono-repo.

This is already supported since quite a long time, if you simply open a subfolder of a git repo.

+1

Sublime and Atom do it you should to. No better reason. This is the NEW MS, get it done guys, i have complete faith in you. :)

Hello,
@inestyne if you please read prior posts like from @Jeyanthinath you would be aware of using VSCode Insiders to evaluate this feature already. There is even a roadmap to check. So please use the product and provide feedback before it migrates to stable so we all get the best product possible. Thank you. Good day.

Just read the thread and use Insiders OMG. I'm gonna unsubscribe... you trolls that doesn't read are impossible. Thanks @pr-yemibedu

Sensitive

Since this thread is 2 years long, and the feature seems to be in the Insiders' build now, is there a way to mark this thread so that is more obvious than reading the entire thread from the top?

One thing that is missing is the ability to open up a new window with a new workspace from the CLI.

@jearle A new window/workspace should be created as before with code-insiders <folder>, no?
code-insiders -a <folder> is needed to add the folder to the current window.

@Jeyanthinath thanks! Been doing the same thing as @JamesTheHacker and it will help me!

@Tyriar to get the functionality I wanted I have to execute the following commands:

code .; code -a .

code . opens the folder as a non workspace, and then the code -a . attaches it's self to the previously open window as a workspace allowing me to open the same folder more than once.

I personally think this also needs to be changed. I am working with ionic and a custom server in two different git repos and it's not very easy. The ability to at least have two separate "project tabs" open or something would be great.

I switched from Atom because of how buggy and slow it was.

@dark-swordsman you can enable nativeTabs on mac

@felixfbecker is this possible on Windows?

Edit: I searched through the settings file completely and there is no option for that. That's why I'm asking.

Edit2: Also, there isn't a clear resource on how to enable vs insiders

Hello,
@dark-swordsman you do not enable VS Insiders. It is a build of VSCode that has some extra features that have not finalized to stable and in a way gives you an extra editor namespace to work with (You can install them side by side without conflicts of settings or extensions). Thank you. Good day.

Support for multi-root workspaces is now enabled by default in the stable release.

Please refer to our documentation for a full explanation of all the features that come with it. Extension authors should refer to our wiki that explains the new extension APIs to make your extension ready for multi-root workspaces. We are happy that quite some extensions have already started to adopt the new multi-root API, thanks for that!

Please do not hesitate to file issues for multi-root as you encounter them, we are still planning on making tweaks and providing additional APIs for extensions to work with multi-root workspaces in the future.

This is great, but when will it be available? You say it's in the stable build, but I have the latest Stable build (1.17.2) and can't update to it. Also, in the documentation that you just referenced, it said it's still in the Insider's build and will be in the stable release soon.

I understand it may be a small while before the next build is released, but I saw this notification expecting it to be available. Sorry if I'm being impatient, I am just getting to a point in my current project where this is extremely necessary and is partially responsible for preventing me to continue.

Edit: I apologize for my impatience. I was just trying to open a new window the manual way (call the .exe again) and it wasn't working, but didn't look in File > Open New Window. This will work for now. Looking forward to the release of the next build. 👍

@bpasero Please close this #35849 open issue since the expected functionality has done as part this #396 feature.

Just a quick question. Is it possible, when I have opened more folders, to switch which folder I want to compile? At the moment it is always the first one in stable version.

EDIT: This might be for the creator of PlatformIO extension, but I am asking on both sides. Just in case...

@DJManas it sounds like that this is up to the extension you are using to decide, so you should ask the author of the extension.

@bpasero Ok, I did in parallel, thank you for reply.