fix(views): register a fallback default view container so contributed views don't crash registration

[nikolai-vysotskyi]

What

Register a minimal default Sidebar view container (workbench.view.explorer) inside the views service-override when none exists, so VS Code's views extension-point fallback resolves instead of throwing.

Why

In a partial setup that doesn't include the files explorer, ViewsExtensionHandler.addViews resolves a contributed view's target container as container ?? getDefaultViewContainer(), where getDefaultViewContainer() is viewContainersRegistry.get('workbench.view.explorer'). With no Explorer registered that's undefined, and the next line reads .extensionId off it → an uncaught TypeError, which aborts the entire contributes.views pass. The net effect: every extension's contributed sidebar views silently fail to register (hit with anthropic.claude-code and openai.chatgpt, but it's generic — ms-vscode.js-debug contributing into the missing debug container triggers it too).

Stack:

TypeError: Cannot read properties of undefined (reading 'extensionId')
    at ViewsRegistry.addViews (Array.forEach)
    at …_handleExtensionPoint
    at …_resolveAndProcessExtensions
    at …_initialize

Full investigation + traces: #804.

Change

ensureDefaultViewContainer() in src/service-override/views.ts, called at the top of getServiceOverride(). It registers a hideIfEmpty default Sidebar container only if workbench.view.explorer isn't already registered, so setups that DO include the explorer (or already register it) are unaffected. This mirrors the workaround discussed in #804.

Notes

• An alternative would be a defensive null-guard in viewsExtensionPoint.addViews (a vscode-patch) so the fallback degrades without throwing even when no default container exists at all — happy to switch to that approach instead if you'd prefer it.
• Verified in our app: the repeated uncaught extensionId crash drops to 0 and contributed sidebar views register + render (a remote extension's sidebar webview-view now shows). I was not able to run the full repo build locally (it pulls the VS Code sources via install-vscode), so please rely on CI / a quick local check for the build.

Refs #804

[CGNonofr]

Thanks! it would probably better to be in viewCommon though, so that it also impacts the workbench service override

[CGNonofr]

Does it really need to mimick the explorer settings, and any other value would be fine (except isDefault: true and the ViewContainerLocation)?

[CGNonofr]

Ok I've just checked the code, and it seems that workbench.view.explorer is required :)

[nikolai-vysotskyi]

Moved it to viewCommon.ts as you suggested, so it also covers the workbench service override — and kept workbench.view.explorer as the id (thanks for confirming that's the one getDefaultViewContainer() requires). Force-pushed; the diff is now a single file.

On the null-guard alternative from #804 — I agree it'd be cleaner/less hacky, but it'd live as a vscode-patch on viewsExtensionPoint, and I couldn't run the full install-vscode build locally to generate/verify the patch. Happy to switch to that route if you prefer — could you point me at how you'd like the vscode patch regenerated, or take it from here if that's quicker? Otherwise this viewCommon version is ready to go.

[CGNonofr]

Maybe https://github.com/CodinGame/monaco-vscode-api/wiki/How-to-upgrade-to-next-vscode-and-monaco%E2%80%90editor-versions can help you

[nikolai-vysotskyi]

Thanks for the pointer! I tried to take the guard route, but I can't reproduce your install-vscode build environment here (no mise, and pulling/patching/building the full VS Code source to generate + verify a real vscode-patch isn't feasible on my side), so I can't ship a verified patch myself.

In case it's quick for you, here's exactly where it throws — in viewsExtensionPoint.ts (ViewsExtensionHandler.addViews), deminified from the bundle:

const l = this.getViewContainer(key)            // undefined for an unknown container id
l || collector.warn(/* "… added to 'Explorer'." */)
const d = l ?? this.getDefaultViewContainer()   // getDefaultViewContainer() => viewContainersRegistry.get('workbench.view.explorer')
// …later, in the per-view loop:
… d.extensionId …                               // TypeError when d is undefined (no target container AND no Explorer)

So the guard would be: when d is undefined (neither the target container nor the Explorer default exists), warn + skip those views instead of dereferencing d — e.g. right after the const d = … line:

if (d == null) {
  collector.warn(/* container '{key}' not found and no default view container is registered */)
  continue
}

Totally your call on which you prefer — the guard (you'd own the vscode-patch), or merging the viewCommon registration in #805 as-is (it's verified working on our side). Happy to adjust #805 either way.

[CGNonofr]

What about #806 ?

[nikolai-vysotskyi]

Superseded by #806 — CGNonofr's source-level guard in viewsExtensionPoint.addViews is the cleaner fix. Thanks!