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.

[nvcnvn]

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.

[Tyriar]

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

[alefragnani]

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.

[dadreggors]

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

[Tyriar]

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

[dadreggors]

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

[Tyriar]

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

[dadreggors]

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.

[kachkaev]

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.

[pixelbyaj]

Why Microsoft people not concentrating on this ?

[mulianju]

+1

[elvestar]

+1

[jamietre]

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.

[saada]

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.

[douglas]

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!

[mrlami]

+1

[gilboa23]

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.

[nkostadinov]

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.

[scharf]

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.

[KioriSun]

This is really needed.

[joerx]

+1. Dealbreaker for me.

[jeffery9]

This is really needed. +1

[jeffery9]

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

[ghost]

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!

[soljohnston777]

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

[enyachoke]

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

[Tyriar]

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.

[soljohnston777]

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

[jamietre]

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

[scharf]

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

[jamietre]

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.

[soljohnston777]

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

[aga5tya]

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.

[philicious]

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

[doughywilson]

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

[kennethtaylor]

+1

[d-sparks]

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

[danechitoaie]

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

[dmccaffery]

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

[danechitoaie]

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

[dmccaffery]

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

[min20]

How about this?

[nvcnvn]

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.

[mkszepp]

+1

[Fenkiou]

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

[williamokano]

+1

[nucleardreamer]

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

[dadreggors]

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.

[hugobessa]

+1

[dbkaplun]

+1