This has been the case for some time, see intersystems-community/intersystems-servermanager#232. The web version does almost nothing, so we haven't made any effort to bring it back by making the server manager web-enabled.

cc @isc-rsingh @gjsjohnmurray

The main reason for web version is to get basic Syntax highlighting and Outline support
I don't see any reasons to tight it with ServerManager

The PR that added the dependency was #1270. We collapsed the two view containers (the InterSystems logo and the toolbox) into one that is shared by both extensions. It made more sense for this extension to depend on server manager than the other way around, as other extensions unrelated to this one may want to add a view to the view container. We won't be removing this dependency, but we can consider having serer manager publish a "dummy" web extension that fulfills this dependency.

It does not deny the fact, that this extension worked in web and now it's not allowed to work there, due to this dependency
it's a breaking change

I propose creating a stub extension that simply contributes the view container. It should be trivial to build this as both web and desktop. Then I'd make the ObjectScript extension depend on this new one rather than on Server Manager. I'd also remove the view container from Server Manager, make it dependent on the new extension, and make it use the new view container for its Servers view.

That's an interesting proposal, but I don't think it's the best approach. Users already have trouble understanding our current extension pack, specifically why there are three extensions and how they work together. Adding a fourth just to break out a UI element isn't going to make that any clearer. I think there are two better paths we can take:

1. Remove the web extension support from future versions of this extension. This hasn't been touched since Dmitry's original PR over four years ago, and we've heard nothing about it outside of 2 reports that it was broken in the 13 months since we broke it. This isn't an area of focus for us and is unlikely to be in the future. The few users who care about web support can stay on version 2.10.5 in their web environments.
2. Make Server Manager supported in the web. This should be as simple as adding a web-extension.ts file with an empty activate() function, and some small package.json and CI changes. This would get the few web users unstuck without having to be pinned to an old version, and leaves the door open to enhancements in this area in the future. It also doesn't involve changing the extension pack.

While I think option 1 is a more honest assessment of our priorities, I support us implementing option 2 as part of the next Server Manager release. cc @isc-rsingh

@isc-bsaviano I disagree. I think publishing a web-installable Server Manager that does absolutely nothing could lead to confusion. In the web context it will show up as an installed extension, yet none of the features described in its README will be present. This may lead to bug reports, and perhaps raised expectations that the missing features will someday be implemented.

The stub view container extension doesn't need to be included in the extension pack. Installing either Server Manager or ObjectScript will automatically install it once published (which it isn't yet).

You can try the mechanism out already.

1. Download https://github.com/intersystems-community/vscode-intersystems-viewcontainer/releases/download/v1.0.0-beta.1/viewcontainer-1.0.0-beta.1.vsix and install it.
2. Fetch the dev VSIX from the artifact on https://github.com/intersystems-community/vscode-objectscript/pull/1494/checks and install it.
3. Fetch the dev VSIX from the artifact on https://github.com/intersystems-community/intersystems-servermanager/pull/257/checks and install it.

I think publishing a web-installable Server Manager that does absolutely nothing could lead to confusion. In the web context it will show up as an installed extension, yet none of the features described in its README will be present. This may lead to bug reports, and perhaps raised expectations that the missing features will someday be implemented.

This is true of the web support for this extension, so why go through all of this trouble just to enable that? I will talk about this with Raj and see what he thinks.

@isc-bsaviano I disagree. I think publishing a web-installable Server Manager that does absolutely nothing could lead to confusion.

Could a web installable server manager work normally, but just not have a place to persist config between sessions?

Could a web installable server manager work normally, but just not have a place to persist config between sessions?

There are a few Windows-only features that definitely won't work, but I think that everything else should. The only other dependency is axios, which is supported in the browser.

@daimor I'm not sure how much (if at all) you use Server Manager in non-web VS Code scenarios. But in your web VS Code scenarios are there any features of Server Manager that might be useful if we were to webify that extension (related intersystems-community/intersystems-servermanager#232).

all of this trouble

@isc-bsaviano I'm not clear what trouble you mean. The extra extension is ready to publish, and the tiny PRs for the 2 extensions are only set as Draft because we need to coordinate publication if we want to avoid users getting two InterSystems logos on their Activity Bar, even if only during transition.

Syntax highlighting, outline and code navigation is only needed for web

Syntax highlighting, outline and code navigation is only needed for web

You're never interacting with IRIS instances anywhere, right?

Mostly use in GitHub, just simple checks on code.
So, no servers for sure

Raj an I spoke about this and we agree that the best approach is to make Server Manager fully supported in the web. This will open the door for any extensions that depend on Server Manager to use server connections on all platforms. I will do this work an open a Server Manager PR when it's done.