Allow a workspace to show individual files from other folders

[Sneezry]

Update from @bpasero: this issue was renamed based on the discussion at the end (see #45177 (comment) and above)

Original below:

• VSCode Version: 1.20.1
• OS Version: Microsoft Windows [Version 10.0.16299.248]

Steps to Reproduce:

N/A

Does this issue occur when all extensions are disabled?: Yes

---

Currently, .code-workspace only contains folders field which allows to add folders into workspace. I prefer a way to add single files into workspace for the entire project, such as README or something else.

[TuxVinyards]

I seem to be able to add files to the 'workspace' by just using file > open. However, they don't show in the workspace side bar, so can't do things like rename when doing versioning numbers. Also 'gitlens' doesn't seem to track them either.

[TuxVinyards]

Or, to put this in different words:
I can create a workspace from a couple of folders. But if I want to add a couple of files as well, I can't get the same workability The .workspace file seems to record the files that I have open but as they don't show in the side bar ....

[OwenPattison]

I've had the same issue this week where I've altered the structure of my solution so that i only have single package.json and tsconfig.json in the root of my solution, where previously there were multiple of both package.json and tsconfig.json located inside of a corresponding 'App' folder, this meant in my workspace i could add each 'App' folder and vscode would be happy - no errors.

Now that I've changed the structure to have a single package.json and tsconfig.json which handles each app the workspace does not include the files due to them now being located in the root which leads to ts errors in my files.

The only workaround i have currently is to include my entire solution which isn't very desirable.

Having the ability to add individual files to the workspace means i could retain a workspace that only has my desired files in but means i could include the necessary files to not have errors.

[qiulang]

.gitignore, README and docker-compose.yml(my case) are the good examples to be in the root of my app folder.
Besides, I feel weird that although I can't add those files to my workspace I can just open a new window to open my app folder. All files inside my app folder will show but I can't debug my app (vscode shows 'no configuration') like when I use workspace.

[jalovatt]

Yes please.

Due to the setup of the repository I'm working in, a particular project might have its own subfolder but also has to have a package file at root-level. Would be great to have the package as part of the workspace.

[IvanG96]

And i would say even more. Due to the project specific that i'm working on, i have several c# projects in the several folders that included into one visual studio solution. And there are hundreds of xml files in this folders that can't be made as part of solution.
So it would be really great and convinient to include all of them into vs code workspace by simple pattern like \xmlfolder**.xml

[bpasero]

I am closing this "as designed". This is not a scenario we will support anytime soon. Please also see https://github.com/Microsoft/vscode/wiki/Issue-Grooming#out-of-scope-feature-requests

[jefferysterner]

It's ridiculous that you aren't doing this. Not doing it defeats most of the purpose of having workspaces.

[TuxVinyards]

@bpasero I have to wonder if the bar isn't being set a bit high. There's an under-diiscussion label for bugs. Maybe the same is required for feature request.

@Others since contributing to this thread have wondered at times if it is actually desirable:

1. I have started using symlinks as a work around, storing the files in the main folder and placing external links to these where needed.

2. Other IDE's don't have, or may not have this feature. This feature would limit the intersharability of code and makes me wonder about my support for it.

[devuxer]

Looking at the criteria in https://github.com/Microsoft/vscode/wiki/Issue-Grooming#out-of-scope-feature-requests, I'm a little confused why this was closed.

1. Does the functionality described in the feature request have any reasonable chance to be on the next roadmap?

This doesn't really seem to be a criterion on its own. It's very dependent on (2) and (3).

2. Are the costs to implement the functionality reasonable given the size of our team? I.e. can we afford the feature?

If allowing some loose files or folders at the same level as project folders has a particular high cost, it would be helpful to get a brief explanation why that is the case. The project folders themselves would seem much more complicated to implement, given all the special UI treatment they get. I would also argue that allowing a .vscode folder for the whole workspace, rather than embedding settings and launch configuration into the code-workspace file and ignoring certain settings set at the project-level that conflict (like zoom), you would end up with a much cleaner, "fully baked" system.

3. Has the community at large expressed interest in this functionality? I.e. has it gathered more than 10 up-votes or more than 10 comments over the last 6 months? Just for reference, the up-vote criterion alone covers more than 500 feature requests as of right now, September 10th, 2018. We also look at the duplicates for this analysis.

This post has 28 upvotes in the last seven months and this comment will be the 10th.

Would the team consider giving this one more look?

EDIT: better make that 125 votes and counting, as of 11 MAY 2020.

[MrRobboto]

30th Upvote.

I was very glad to start using workspaces, instead of having my entire root folder in VS Code which has word documents and crap. I was able to just have the main folders I code in (Web, API, and DB for this main project I'm on).

I was surprised to find I couldn't add a couple other files to the workspace that would be nice to show up right next to the main folders. Specifically Readmes would be nice and also I like to put the API .sln there so I can quickly go to view it in explorer and open it in VS (I avoid going in there).

Anyway, this seems like it would obviously be on the roadmap to go along with Workspaces as they are. If there's a ton of other backlog more important I'd get a delay but to close this seems wrong.

If a workspace files feature is so far down on the list that it will never get done, then workspace folders should be right there with it and shouldn't have been done. I'm not following the logic that implementing with folders was important enough to do and just stop there...

[MrRobboto]

@TuxVinyards

Thanks for suggesting Symlinks, I ended up going this route as well for a workaround and it's not too bad, basically achieves what I was trying.

I added a "Links" folder to my workspace which just has a list of Symlinks to files I wanted to include in the workspace.

[i-am-malaquias]

There does seem to be interest for this feature.
Maybe an easier way to implement this would be the ability to hide files/folders from the workspace structure?
I wouldn't mind adding the entire root folder and then choosing what I don't want to see in the explorer, probably.
This approach also makes more sense in cases where you create new files in the project, they would automatically show up in the explorer if they're not in an exclusion list, otherwise you would have to manually add new files to the explorer.

[MrRobboto]

@MrGoDuck @TuxVinyards

Yeah, that would work and offers plenty of flexibility - I would absolutely be in favor of that.

PS - My hard links are breaking (not sure which app is overwriting files but it happens - I hope it's not VS Code). So I had to get rid of my "Links" folder. I am back to just searching for the files I'm looking for when I'd ultimately like hard links in the root, included in the workspace.

Ex of the ideal:

API
--Models
----Model.cs
----A bunch of other files crowding the space...
Web
--Models
----App Model.ts
--Etc.
APIModel.cs (h link included in ws)
WebModel.ts (h link included in ws)

A bit unrelated but it seems like VS Code might be the one breaking my hard links...! I had the two links in a "Links" folder included in the workspace and it was working perfectly for a session and then broke. I didn't open the files in any other app.

[TuxVinyards]

@MrGoDuck Sounds like the start of an algorithm. What are you like at Typescript? Might work adding lines to the .jsn. manually ..

Not tried the above. @MrRobboto my symlinks method is still working for me. Maybe VS Code doesn't play nicely with links? I have only 'real' files in the working folder. The outside files as links works but does have limitations. Maybe an OS issue?

[Jeffrey-Hall]

I found it hard to believe I could not add files to my workspace. Please reconsider this feature request.

[josiah47]

I too found it ridiculous that this was not a feature.

[raosatish]

Yes. Please add the ability to add individual files to the workspace.

[safield]

+1

[IvanG96]

Please add the ability to add individual files to the workspace by some pattern (e.g. *.txt). Thank you. Best regards, Ivan Grechko On Wed, Nov 28, 2018 at 11:25 PM +0300, "safield" <notifications@github.com> wrote: +1 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[EstevezCarlos]

+1 MS PLZ

I have a walk around:

1. I add folder that contains files I need.
2. I install Make Hidden extension.
3. I hide files that i do not want to see in my workspace.

[i-am-malaquias]

@EstevezCarlos
This should be available without the use of an extension.

[dlordi]

From your reply, I understand the main problem is explaining to users how the "files" workspace would work.
Would it help calling this feature as a "per-project bookmark/favourite files list"?
It would get its own "root folder", visually distinct from other real folder (distinct icon?)

[johndog]

I think a good metaphor for this problem is git and its sparse-checkout feature. A git repo has a root, but when you sparsely checkout the tree, you have a filtered view of that tree on disk. The sparse checkout list is a list of file path patterns that essentially filter the view.

Applying this metaphor to vscode, the top level schema of multiple-roots can be maintained as-is; your multi-root workspace is still a set of root directories. But now you would have the ability to filter which files are visible to (and within) vscode for each of those directories. If you want individual files, you add the root directory containing it, then specify a filter. If there was an "add individual file" feature (which isn't technically required), it would be translated into this process.

[bpasero]

@tschoepping

The original issue of this thread, however, is of functional nature.

I think most issues start like that but almost all changes have an impact on UX. We cannot just ignore the UX problem when we fix a "functional" issue. I think I made the UX challenge clear in my comment, so I will not repeat it. But maybe I add a point to it: workspace files can be crafted by someone that understands the concepts but then used by many that do not. We try to make workspace files as simple as possible to reduce the friction.

Moreover, if explicitly excluding files is a viable option, I do not understand why explicitly including files is not.

👏 , I think we are getting somewhere constructive. I think #869 will help here a lot and I agree it is needed for this purpose.

As others pointed out, this is a basic feature even rudimentary editors support and developers simply expect it to be there.

Can you give me an example of a "rudimentary" editor to look at? Maybe there is another solution possible that does not involve making changes to workspace files?

@dlordi

Would it help calling this feature as a "per-project bookmark/favourite files list"?

Maybe, but then on the other hand I think a workspace file can be used for this in combination with #869, so we would not have to bring in another concept? You can even change the name of the workspace folder in the .code-workspace file to make clear the folder is about some loose files of the repo.

@johndog

I think a good metaphor for this problem is git and its sparse-checkout feature.

Yes, we support that but limited to folders only for the sake of simplicity.

[devuxer]

@bpasero,

I agree about the importance of UX, but I think this problem is very solvable without compromising UX.

Basically, what we want is a multi-item workspace (where an item is either a folder or a file). Details:

• An additional (optional) node, "files": [], would be added to the code-workspace JSON schema.
• Settings could be applied to the overall workspace or any root folder contained within it (just as it currently works).
• Root folders and files would both have a circle dot added to their icon to make it clear they are a reference to an item on disk.
• Attempting to drag a root file to a root folder or subfolder would result in the file being removed from the list of root items, and a copy of that file would be placed in the target folder.*
• Attempting to drag a file in a root folder or subfolder to the root would result in the file staying where it is, and an entry would be added to "folders".*
• Attempting to drag a folder or file from the file system to a workspace root in VSCode would result in an entry being added to "folders" or "files" (and no change to the source items on disk).*

*Before completing this (potentially confusing/destructive) operation, an explanatory dialog would appear (with the option to "never show this again"). This already exists for dragging files around within a root folder.

What about your concerns?

• Can you have a workspace with just files?
  • Sure, why not?
• How can a user distinguish a single-folder workspace with a files-only multi-item workspace?
  1. You continue to put (WORKSPACE) in the title in the Explorer
  2. You add circle dots to all root files (just as you do with folders).
• What happens if a file/folder is dragged around?
  • A dialog appears explaining what will happen (with the option to never show again)

[tschoepping]

@bpasero

I agree that UX is very important and one of the biggest strengths of VSC, imho. However, your statements sound like you don't consider any functional changes that might entangle modifications/challenges for the UI categorically. Of curse, any functional change must be communicated clearly to the user to be useful.

That said, deliberately not supporting files is a "feature" that needs to be communicated to users as well. But as this thread and the other one you pointed out (#869) show, communication in this regard is clearly lacking. Everyone understands the concept of files and folders, but nobody seems to understand, why VSC does not intent to support files the same way as folders, causing a sort of "friction". Perhaps there are reasonable arguments for this decision, but so far they have not been communicated clearly (for 7 years!).

As mentioned earlier, Notepad++ supports this feature as a simple editor. QtCreator is a more sophisticated example, supporting this as well. The approaches they take are rather cumbersome, imho, and I definitively prefer the JSON-based method of VSC. Perhaps you should have a look at SublimeText.

In any case, a solution to this issue will most certainly involve changes to workspace files, simply because it is about the contents of workspaces.

[bpasero]

@tschoepping it is probably not a secret that multi root workspace files were inspired by Sublime Text Projects and thanks for pointing out to revisit their documentation. From https://www.sublimetext.com/docs/projects.html I see no evidence that I can add files to a project. From my testing I am not able to add loose files either.

However what I find cool is support for configuring what to include/exclude in any of the roots. So given a project config of this:

{
	"folders":
	[
		{
			"path": "/Users/bpasero/Desktop/test-ts",
			"file_include_patterns": ["package.json"],
			"folder_exclude_patterns": ["**"]
		},
		{
			"path": "/Users/bpasero/Development/Microsoft/vscode"
		}
	]
}

The result will be:

I find this a good approach and it goes into the direction of what I had mentioned in #869

What is missing in VS Code to support this is:

• a way to configure includes such as Exclude all files except for... #869 or Add !-prefix parsing to glob util #134415 suggests
• a way to target a root folder from the workspace configuration [1]

[1] since glob patterns are evaluated relative to the root folder, we need to come up with some syntax to let a glob pattern target one of the root folders, for example:

• <vscode/[pattern]>
• <vscode:[pattern]>

[communque]

FWIW I built a personal extension. Haven't posted it b/c of its limited scope, but the basic idea is this:
It creates a new Sidebar Panel (in addition to the existing Workspace Panel. I think everyone would prefer to simply extend the existing Workspace panel). It uses the same (albeit modified) .code-workspace file.

The original plan was to create a panel whose file list would be populated

• by the existing "Folders" array in the 'workspace' file
• by a newly-added "Files" array for additional items
• by an array of regex entries, so that file items could be included dynamically.
  There's really no limit to what's possible.

I got as far as the "Files" array, it worked, and discovered the others weren't even needed, at least not immediately, so to date haven't gone back and elaborated the extension. Haven't used the built-in Workspace panel since.

In the end it would seem there's probably no need to even distinguish between "Folders" and "Files" or even a "Regex" arrays. They could all be listed in one array, and a bit of coding could figure it out.

[tschoepping]

@bpasero
That's what I was referring to. This way you can add individual files from any directory as described here. That method is quite verbose, though, so that a files node would be a much more readable short version.

Thank you for reopening this issue!

[bdetry]

Thanks, @tschoepping, for the stack overflow answer. I have used it to do this walk arround :

So I add the "folders" I want and the folder with everything too (the last "folder")

Then I ignore everything except the ones I want. In this case "package.json" but It will be in another "workspace folder" (the one I named Project folder)

[illustrious-otter]

I use projects with just a few files all the time - it is often required to make changes in a group of functionally related files that live in completely different places.

Another common use is top level code (perl/python/bash etc.) that uses a relative library dir, but itself lives amongst a bunch of other executables.

I am a recent convert to vs code after decades of using bbedit - for an example of how individual files can work easily and powerfully in a workspace, take a look at bbedit's implementation (they call them projects) - it is excellent and shows that it can be done without any UX confusion. I greatly prefer this approach over using hard or soft links as they always seem to bite me on the bum eventually...

[EntranceJew]

FWIW I built a personal extension. Haven't posted it b/c of its limited scope, but the basic idea is this: It creates a new Sidebar Panel (in addition to the existing Workspace Panel. I think everyone would prefer to simply extend the existing Workspace panel). It uses the same (albeit modified) .code-workspace file.

I would really appreciate it if you were to release this.

[tsanyqudsi]

Thanks, @tschoepping, for the stack overflow answer. I have used it to do this walk arround :

So I add the "folders" I want and the folder with everything too (the last "folder")

Then I ignore everything except the ones I want. In this case "package.json" but It will be in another "workspace folder" (the one I named Project folder)

I use this approach and I think it's not workaround. I think this is the correct way. This way, there's a choice whether user wants to use Multi Root Workspaces or not without headache.

@bpasero, CMMIW but I think this approach should be on documentation.

[gsimardnet]

To me, it seems like a temporary workaround. The list of "files.exclude" could get very long and this setting applies to every folder so you could inadvertently exclude a "file" (or folder) somewhere else in your project.

[EntranceJew]

I agree, the whole reason for wanting to include only particular files is because of the swathe of other files in a folder I'd otherwise include.

[dlordi]

This looks like another workaround to me.

[kevcmk]

Unbelievable that this isn't addressed yet

[thomasrea0113]

Actually shocking that this isn't implemented yet. Seems so simple

[ch0rl]

+1 would be great to see

[flippinroo2]

+1 - (Can't believe this has been open for 6 years O.o)

I have a single folder "python" that I use to mount into a Docker container.

The folder includes multiple files (the entire reason I need this feature):

• README.md
• .bashrc
• .gitmodules

and then I have multiple sub-directories that each have their own launch.json configurations.

However, those launch configurations don't show up unless the folders are added as a multi-root workspace...

Then the dillema is I can't see the files in the root "python" folder when I do that.

(I currently have them inside of a single launch.json but it's over 4,000 lines long...)

[callahanp]

What kind of confusion would adding a feature that people have been asking for for years entail?

Workaround:
Create a directory for symbolic links to the additional files you are interested in for a given workspace.
Add that directory to your .code-workspace folders list.

No confusion at all, but the extra effort should not be necessary.

I should be able to add something like this to my.code-workspace:

"folders": [ ],
"additional_files": [ "path-to-file", "path-to-another-file" ]

Could anyone explain why the vscode development community has been reluctant to add this feature?