Empty workspace generates a .code-workspace with no folders, so the editor opens with nothing mounted

[achdmbp]

Describe the bug

When starting an empty workspace (one whose devfile has no projects, dependentProjects, or starterProjects, e.g. the dashboard's built-in "Empty Workspace" sample), the che-code launcher generates a .code-workspace file that has no folders array. As a result, VS Code / che-code opens with an empty Explorer and no folder mounted, even though /projects exists and is where the user is expected to work.

The generated /projects/.code-workspace looks like this:

{
	"extensions": {
		"recommendations": [
			"eamodio.gitlens",
			"redhat.vscode-yaml",
			"..."
		]
	}
}

Note the extensions.recommendations block is present (injected by the vscode-editor-configurations handling) but there is no folders entry, so nothing is open.

Che version

7.119.0 (also reproduced on current che-incubator/che-code main)

Steps to reproduce

1. Open the Dashboard and go to Create Workspace.
2. Under "Select a Sample", filter by Empty and start the Empty Workspace sample (a devfile that is just schemaVersion + generateName: empty, with no projects).
3. Wait for the workspace to start and the editor to open.
4. Open a terminal and inspect the generated workspace file:

   cat /projects/.code-workspace
   

Expected behavior

The workspace should open with the /projects directory mounted in the Explorer. The generated .code-workspace should contain a folders entry pointing at PROJECTS_ROOT when there are no devfile projects to add, e.g.:

{
	"folders": [
		{ "name": "projects", "path": "/projects" }
	],
	"extensions": { "recommendations": ["..."] }
}

Runtime

OpenShift Dev Spaces / che-code

Root cause

The workspace file is generated by the che-code launcher in launcher/src/code-workspace.ts, CodeWorkspace.generate().

For an empty workspace:

1. No VSCODE_DEFAULT_WORKSPACE is set and there are no projects, so generate() falls through to the default path branch and creates a brand-new empty object:

   workspace = {} as Workspace;   // no `folders` key
   saveRequired = true;

2. It then calls synchronizeProjects() for projects, dependentProjects, and starterProjects. synchronizeProjects() bails out on the first line when the array is undefined:

   async synchronizeProjects(workspace, projects?) {
     if (!projects) { return false; }   // empty workspace: returns here, folders never initialized
     ...
   }

   So folders is never populated (and never even initialized to []).
3. The launcher writes {} to /projects/.code-workspace. Later, extension recommendations are merged into the same file, producing the extensions-only file shown above.

Because the resulting file is a multi-root .code-workspace with no folders, VS Code opens a zero-folder workspace and the Explorer is empty.

Suggested fix

In CodeWorkspace.generate(), after the synchronizeProjects() calls and before writing the file, ensure folders always contains at least PROJECTS_ROOT when it would otherwise be empty:

if (!workspace!.folders || workspace!.folders.length === 0) {
  workspace!.folders = [{ name: 'projects', path: env.PROJECTS_ROOT }];
  saveRequired = true;
}

This is a no-op for workspaces that already resolve folders (single-project, multi-repo, or a VSCODE_DEFAULT_WORKSPACE file that already lists folders), and it fixes the empty-workspace case at the source.

A PR against che-incubator/che-code implementing this will be linked to this issue.

[rgrunber]

Thanks for diagnosing this. I think the main question is whether there should always be some folder open when the editor starts. Particularly in the case of having a devfile with no projects defined / empty workspace sample, whether that open folder should be the parent (/projects). I could definitely see a case where not having any folder opened would be intended.

@RomanNikitenko , @ibuziuk , let me know your thoughts on this.

[ibuziuk]

@achdmbp thank you for the proposal and PR. My understanding is that the UX that is meant to be fixed is related to the project explorer in the first place:

I could definitely see a case where not having any folder open would be intended.

@rgrunber I agree, but at the same time, imo we should provide a feature toggle / env var to open the /projects by defa
ult.

[RomanNikitenko]

imo we should provide a feature toggle / env var to open the /projects by default

+1 to have an env var (or another approach) as a clear marker what folder should be open by default