Add support for opening multiple project folders in same window

[stoffeastrom]

Right now it doesn't seem possible to opening multiple project folders in the same window which imho is a bit constraining. If you are working on modular modern projects it's a must have to be productive.

[i5ting]

agree, but maybe it is a optimize solution for memory

[yoorek]

+1

[dmccaffery]

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.

[stoffeastrom]

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!

[Tyriar]

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.

[dmccaffery]

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

[yoorek]

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.

[daniel-uzunu]

+1

[nilzona]

+1

[elgris]

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.

[rezonant]

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

[TurkeyMan]

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

[Loren-Johnson]

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.

[rhbecker]

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"

[stoffeastrom]

You mean #2686 is a duplicate of this?

[bpasero]

Sorry, I misread the description and reopened this one.

[Sapunov]

+1

[lepinkainen]

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.

[jolav]

+1

[josebalius]

+1

[mibanez]

+1

[matthewatabet]

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

[kalinkrustev]

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.

[xcorpio]

+1

[shoerob]

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

[anidexlu]

+1

[mdedgjonaj]

+1

[rampage644]

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

[ryanbriscall]

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

[elirenato]

+1

[donaldpipowitch]

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

[mastrauckas]

I hope this feature happens!

[poidl]

+1

[crunchtime-ali]

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

[poidl]

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

[Tyriar]

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

[sunyuu]

+1

[ejmarino]

+1

[jimmynavio]

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

[Gee19]

+1

[arthurhenrique]

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" } ] }

[dadreggors]

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)

[danielsokolowski]

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

[dmccaffery]

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.

[danielsokolowski]

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.

[dadreggors]

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

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

[dadreggors]

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

[dmccaffery]

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.

[dadreggors]

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.