Have extensionKind: "ui" only run in the ui

[alexdima]

• In September, we made "extensionKind":"ui" run on the workspace extension host if the extension is only installed there.
• In October, we have added support for "extensionKind": ["ui","workspace"] to express that an extension can run on either side, but prefers the ui side.
• In October, we have left "extensionKind":"ui" to be able to execute on the workspace side.

---

We should clean this up and enforce that "extensionKind":"ui" only allows an extension to run on the ui.

[alexdima]

fyi @sandy081 @egamma - I have removed that ui extensions are allowed to execute on the remote side.

Still left to do:

1. extensions actions in the viewlet need to also enforce this everywhere and we need to bring back the tests that we removed in September (go back to the August state) @sandy081 .
2. do a pass over extensions in the marketplace or in our product.json which use "extensionKind":"ui" and check, very likely they might need to adopt "extensionKind": ["ui","workspace"] in their package.json or we should do it for them if we run out of time in our product.json.

@sandy081 @egamma LMK if you need any help with point 2, otherwise I consider this done from my side.

[sandy081]

Added code to disable UI extension on Web. Also disallowed installing them.

[sandy081]

Here is the report after analysing extensions in Marketplace

• 148 - Total extensions in market place that define extensionKind
• 88 - UI extensions out of which 21 are in top 200.
• 55 - Workspace extensions out of which 6 are in top 200.
• 4 - UI, Workspace extensions
• 1 - Workspace, UI extensions

Impact Analysis

Treating "extensionKind": "ui" as strict UI extensions has following impact:

88 extensions (21 in top 200)

• will no longer run in dev container
• will no longer run in VSO and user cannot install them in VSO

Impact on VSO is pretty bad.

Mitigation Steps

After discussions @egamma and me came up with following

• Treat "extensionKind": "ui" as "extensionKind": ["ui", "workspace"]. This will allow above 88 extensions to work in VSO
• Those extensions which are tagged "extensionKind": "ui" and cannot run in workspace/remote/VSO eg: Settings Sync -> update the product.json by adding them to strict ui list. eg: "Shan.code-settings-sync": ["ui"].
• Deprecate / Remove string value type for extensionKind from the schema so that we will encourage authors to use the array rather than string type as it has mixed behaviour.
• Also add checks in vsce and block/warn publishing if extensionKind has string value

@egamma @alexandrudima FYI

[alexdima]

@sandy081 treating "extensionKind": "ui" as "extensionKind": ["ui, workspace"] can be done in a single place, so we wouldn't need to adopt anything, except perhaps tests...

vscode/src/vs/workbench/services/extensions/common/extensionsUtil.ts

Lines 51 to 55 in bee5357

	// check the manifest itself
	result = manifest.extensionKind;
	if (typeof result !== 'undefined') {
	return toArray(result);
	}

[sandy081]

• Changed treating "extensionKind": "ui" to "extensionKind": ["ui, workspace"]
• Changed extensionKind property type to be array. Extensions defining the string will see warning. But we still support taking string value internally.
• Created adoption item for extensions for next month - Reach out to extensions to adopt new extension kind behaviour #85824
• Did not adopt VSCE as it is too early. Let's give a milestone or two for extensions to adopt - Validate extensions having string value for extension kind while publishing vscode-vsce#403