Add support for opening multiple project folders in same window
stoffeastrom opened this issue · 380 comments
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.
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:
- As mentioned above many times, you would have to now open multiple windows (not good)
- 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:
- ctrl+alt+p
- Type start of project, eg. "vsc" for vscode
- 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