Vscode: Consistency with the use of "workspace"

[jabacchetta]

Problem

Developers don't know what a workspace is. Here's my recent attempt to clear up the confusion.

Confusion

• The recent list widget groups folder workspaces along with .code-workspace workspaces under a "workspace" heading, indicating that everything in that list is a workspace. Then it gives .code-workspace workspaces a "Workspace" suffix, contradicting the header, and indicating that only those workspaces that are associated with a .code-workspace file are true workspaces.

• The first interaction with the term "workspace" for most developers is going to be the workspace settings. This is setting up users for confusion right off the bat. Because a folder's .vscode settings is initially referred to as "Workspace" settings. But when a .code-workspace file is created, .vscode settings becomes "Folder" settings, while the .code-workspace settings becomes the new "Workspace" settings.

• "Open Workspace" is referring to a .code-workspace workspace (with the dialog only allowing a .code-workspace file to be selected). Same goes for "Add Folder to Workspace..." and "Save Workspace As...".

• An extension's "Disable (Workspace)" option is referring to workspace as defined by my definition in the SO post.

Suggestion

_NOTE: Suggestions will be updated as discussion in this thread evolves._

• In the recent list widget, create two separate headings: "Workspace" and "Folder". Remove suffixes.
• In settings editor, always refer to specific settings with the same reference. "Workspace" tab for .code-workspace settings. "Folder" tab for .vscode settings.
• "Open Workspace", "Add Folder to Workspace...", and "Save Workspace As..." remain unchanged.
• An extension's context menu will show "Disable (Workspace)" or "Disable (Folder)" depending on which is currently active.
• Optionally, come up with another term when wanting to reference both definitions. Whether it's "Project" or something else. Then it would be acceptable to use "Disable (Project)" in the extension's context menu, for example.

[bpasero]

I think we have to be careful to call this "multi root workspace" because you can easily have just one (or actually no) folder in a workspace file. The use case is still that it allows you to store workspace settings for this folder without polluting the folder with a .vscode folder.

[jabacchetta]

Yeah, naming this will be tough. Although I do think that consistency across the UI is more important than the naming itself.

What about referring to everything as "Projects", and then in the recent list widget, for example, changing the heading to "Projects", and giving those projects a suffix "Workspace" for .code-workspace files and "Folders" for single folder projects?

Same goes for the settings... "Workspace" and "Folder" settings, with "Folder" always being used to refer to settings that exist inside a .vscode folder and "Workspace" always being used to refer to settings that exist in a .code-workspace file (as opposed to changing the naming and creating confusion when a .code-workspace file is created).

And then when enabling/disabling extensions, "enable for this project".

[bpasero]

But why would we introduce something new ("Project") that was never used in VSCode so far at all? I do not want to bring in the notion of projects because the next question will be, what kind of project systems we support etc.

[jabacchetta]

Another option:

In the recent list widget, separate them out into two different headings: "Workspace" and "Folder", and remove suffixes all together.

Again, "Workspace" and "Folder tabs in the settings, with "Folder" always being used for settings coming from the .vscode folder.

For enabling/disabling extensions, I suppose it would need to be dynamic. "Enable for this workspace" when a workspace is opened, and "Enable for this folder" otherwise.

At this point, I'm starting to confuse myself, lol.

[bpasero]

We decided to call both single folders and workspace file the "workspace" you are in. You could name the one "single-folder workspace" and the other "multi-root workspace", but then again, a multi-root workspace can have 0-1 roots too.

[jabacchetta]

What about the UI inconsistencies mentioned above?

• Will suffixes be removed in the recent list widget? If referring to both as "Workspaces", then the .code-workspace projects shouldn't have a "Workspace" suffix that would indicate that only those are workspaces.
• When opening a .code-workspace file, what will settings tabs look like? Will what was once referred to as "workspace" settings become "folder" settings still?
• What will "Open Workspace" menu item become? In other words, it wouldn't make sense to refer to both a single folder project with a .vscode folder and a project that's associated with a .code-workspace file as a Workspace, but then have an option for opening a workspace that only allows you to choose a .code-workspace file.

[bpasero]

"Open Workspace" and "Open Folder" are still there so that we can filter the dialog. With our custom dialog it would probably be possibly to be smarter here.

I refer to @sandy081 for settings.

[jabacchetta]

Yeah, I definitely understand the need to filter the dialog, but again, this is a UI inconsistency that is going to confuse users. At times, both are being referred to as a workspace. At other times, the UI is using the term workspace to refer only to projects associated with a .code-workspace file.

I think, looking through the forum posts that I linked to, it's clear that this has become a confusing issue. Even the answers to those questions are all over the map. And the UI inconsistencies are the biggest cause of this confusion.

[jabacchetta]

Expanding on earlier suggestion:

• In the recent list widget, create two separate headings: "Workspace" and "Folder". Remove suffixes.
• In settings editor, always refer to specific settings with the same reference. "Workspace" tab for .code-workspace settings. "Folder" tab for .vscode settings.
• "Open Workspace", "Add Folder to Workspace...", and "Save Workspace As..." remain unchanged.
• An extension's context menu will show either "Disable (Workspace)" or "Disable (Folder)" depending on which is currently open.
• Optionally, come up with another term when wanting to reference both definitions. Whether it's "Project" or something else. Then it would be acceptable to use "Disable (Project)" in the extension's context menu, for example.

[sandy081]

I agree it makes sense to call settings from a folder always Folder settings which makes it consistent across single folder and multi root folder workspace.

@roblourens FYI

[andrecasal]

I think it would make a lot of intuitive sense to explain that VS Code assumes that any opened folders are an implicit workspace and that we have the ability to create an explicit workspace as a .code-workspace file.

Something like this:
VS Code assumes any opened folders as an implicit workspace and settings for each root folder go inside each root's /.vscode folder. We can also create an explicit workspace as a .code-workspace file which can contain none or more root folders. An explicit workspace .code-workspace file without any root folders can be used to save custom settings, useful for remote development for example, or with multiple root folders where you might have a repository with your product's source code along with the product's documentation which you'd like to keep current. There is no advantage to an explicit workspace .code-workspace file with only one root folder over an implicit workspace that automatically reads settings from the /.vscode folder, however.

I suggest we use implicit workspace and explicit workspace to differentiate between the two use-cases.

[nemchik]

I wouldn't mind to see Project Folders added to Workspaces (where a workspace is the vscode workspace and a project folder gets added to your tree).

With that in mind, some people may choose to run a single project per workspace. That's up to each person to decide how they want their root.

[edburns]

I just submitted a PR to address the documentation side of this issue: https://github.com/microsoft/vscode-docs/pull/3154 . Please consider it.

[vscodebot[bot]]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodebot[bot]]

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[Spenhouet]

_While reading the following, keep in mind that I write this to point out my confusion about VS codes "workspace" concept and the term they are using for it._

I just came across this since I opened our project (single folder project) as workspace and my extensions stopped working:

This setting cannot be applied in this workspace. It will be applied when you open the containing workspace folder directly.

That makes absolutely no sense to me.

Why is a single folder project not a workspace?

Why are extensions not working in a workspace?

If this "workspace" concept is so useless, then why is VS code trying to force users to save a workspace file for projects?

Every other IDE I worked with before had such a "workspace" file. But it was always referring to a single folder project. I intuitively expected that this is the same with the VS code workspace, but it is not. It only starts to make sense with multi-root workspaces.

Could someone explain to me how such a multi-root workspace is meant to work? Given multiple different Git projects that should all use the same VS code settings, extensions and launch configs.. how to combine this. Does the multi-root workspace with settings get an independent Git repository? Don't forget that extensions stop working as soon as we start using a workspace...

What a confusing mess.
After googling the above warning message and figuring out what VS code refers to as "workspace", I was sitting here like "what are they doing".

[codeputer]

Within DAPR, I have a launch settings to be:
"program": "${workspaceFolder}/bin/Debug/netcoreapp3.1/RoutingSample.dll",
but it cant' find the file....

So I'm in the weeds now trying to understand how {workspaceFolder} is derived - or at least allow me to view what it becomes... this statement actually fails, and I'm wondering how to change the work space directory as this statement isn't working, and it's part of a well established library.

[mburszley]

@codeputer ${workspaceFolder} resolves to the file's containing folder in the multi-root project, not the .code-workspace file. See #98424

[joe733]

At UI level I've a suggestion:

If folders could be switched like the servers in Discord (top tabs is also an alternative) I think it will be cool! A default workspace manages the root .code-workspace files.

[MarcosCalvi]

Well, obviously there is a lot of confussion around the concept of Workspace

The only thing that would make sense to me is a workspace has its own launch configurations, git configurations and the opened files you are working on in that workspace so you could have different independent projects in the same window. Switching the workspace in that window would switch the files you are viewing and the configurations you have available. It seems obvious, I don't understand all the confussion.

What do you think of that?

[tamuratak]

Related to microsoft/vscode-docs/issues/3547

[AlbertoFabbri93]

I agree that something should be done in order to clarify the difference between workspace settings and folder settings.