Add a setting to not promote workspace folders to top level if they are children of another top level folder

[bpasero]

In case a multi-root configuration is composed of workspace folders that are overlapping (e.g. one is the parent of the other), add a setting to not promote those workspace folders are top level folders of the file explorer that are already included in another workspace folder.

Extracted from #45399

[DanTup]

It may be useful to render them with an overlay on the icon (or a different icon?) or something to make them more obviously in the tree.

[xster]

Considering a file structure like:

my_repo_folder/  
  |- package_1/   <-- WorkspaceFolder
      |- example/   <-- WorkspaceFolder
  |- package_2/   <-- WorkspaceFolder
      |- example/   <-- WorkspaceFolder
  |- package_3/   <-- WorkspaceFolder
      |- example/   <-- WorkspaceFolder
  |- package_4/   <-- WorkspaceFolder
      |- example/   <-- WorkspaceFolder
  |- package_5/   <-- WorkspaceFolder
      |- example/   <-- WorkspaceFolder

It gets super confusing because there's a bunch of projects called example where it's very hard to figure out which one's which because the hierarchy is flattened.

[DanTup]

For Flutter, we're still seeing issues that stem from our handling of projects in sub-folders. It came up Dart-Code/Dart-Code#1248 and here just in the last week.

Users expect to be able to open a parent folder and the projects inside sub-folders just work as if they'd opened them directly. If we "upgrade" the project folders to workspace folders silently, they all get duplicated in the explorer tree which is really confusing. Our only other option is to track project folders ourselves, but this feels really redundant given VS Code already does it (and we'd have to support those ones too).

[DanTup]

@bpasero do you think it's likely this will happen anytime soon? It continues to come up from people that want to open repositories containing many projects nested deep in a tree (most recently Dart-Code/Dart-Code#1549) and implementing my own tracking of project folders seems to somewhat undermine the Workspace Folders feature.

[Samuel-B-D]

One thing I do that seems to work well is, considering the following structure:

• project
  • common
  • frontend
  • backend

I define a code-workspace similar to this :

{
    "folders": [
        {
            "path": "common"
        },
        {
            "path": "frontend"
        },
        {
            "path": "backend"
        },
        {
            "path": ".",
        }
    ],
    "settings": {
        //...
        "files.exclude": {
            // ...
            // Exclude the 3 main folders (included as workspace folders)
            "common": true,
            "frontend": true,
            "backend": true,
        }
    },
}

Result is that the "project" part in explorer does not show the common, frontend and backend folder but everything show properly in the respective project folders.

[DanTup]

@kazelone thanks, I hadn't thought of that! I don't think it's something I could easily wrap up in my extension though (I don't want to be messing around manipulating the users workspace settings).

That said, (anecdotally) I don't think many of my users are using workspace folders - they seem to prefer to just open up the root folder than maintain a workspace file - which means I'm slowly re-implementing a bits of workspace-folders in my extension so when users perform certain actions I can find the correct one (or ask them to select from a list) 😞

[ob]

@isidorn any progress on this?

[isidorn]

no

[Toub]

One thing I do that seems to work well is, considering the following structure:

* project
  
  * common
  * frontend
  * backend

I define a code-workspace similar to this :

{
    "folders": [
        {
            "path": "common"
        },
        {
            "path": "frontend"
        },
        {
            "path": "backend"
        },
        {
            "path": ".",
        }
    ],
    "settings": {
        //...
        "files.exclude": {
            // ...
            // Exclude the 3 main folders (included as workspace folders)
            "common": true,
            "frontend": true,
            "backend": true,
        }
    },
}

Result is that the "project" part in explorer does not show the common, frontend and backend folder but everything show properly in the respective project folders.

Note that in current version (1.51.1), this workaround cause a very annoying unexpected explorer jump when opening files: #95056

[snebjorn]

Note that in current version (1.51.1), this workaround cause a very annoying unexpected explorer jump when opening files: #95056

Can confirm that it's very annoying.

I was hoping multi root workspace would solve #32693. But if you don't open the root folder it as a workspace or if you open a sub project by itself the workspace settings are not inherited.

And for that reason I'm out. I mean I'm removing multi root workspace again.

[dominikzogg]

@Samuel-B-D the problem with that is, what many extensions can't handle that cause the inherit from files.exclude, their files.exclude, means they are not working for the workspaces folders

[moltar]

Could this be solved by allowing a hierarchy-by-convention using the name prop?

E.g., if I give path a name of foo/bar, then it would render folder foo, with a sub-folder bar in it.

Given:

{
  "folders": [
    {
      "name": "foo/bar",
      "path": "packages/foo-bar"
    },
    {
      "name": "baz",
      "path": "packages/baz"
    }
]

Produces:

├── baz
└── foo
    └── bar

[dominikzogg]

@moltar that should be great, but it does not work like this, currently '/' is a sign like any other in the same.

[moltar]

Right, this was a proposal for how it could work, perhaps behind a setting feature flag.

[g-arjones]

👍

Requiring workspace folders to always be at the top level is very limiting. To be honest, I think most real-world mono repo/monolithic project structures do not do this which requires users to manually add these folders and have them duplicate in the explorer tree.