我的主要动机是获取所有扩展主机上的扩展清单，以找到诸如jsonValidation的贡献。同样的问题也出现在新的anycode贡献中，而htmlLanguage贡献正在#146731中探索。

• 简单的API更改是vscode.extensions.getExtension函数的另一个重载，例如

export function getExtension(extensionId: string, includeAllExtensionHost: boolean): Extension<unknown> | undefined;

• 另外为扩展类型添加一个属性，以便将"相同扩展主机"的扩展与"外部扩展主机"的扩展区分开。可能是一个布尔值，如Extension.isDifferentThanThisExtensionHost或某种扩展主机标识符，您可以将其与类似于vscode.env.thisExtensionHostIdentifier的内容进行比较。
• 最后，遍历所有扩展描述的好方法。类似于vscode.extensions.allAll的功能来补充all属性。或者我们回顾现有的使用情况，以决定是否进行破坏性语义更改...

@alexdima 我在上面的更改中注意到，对于其他主机的扩展(由于已指出的异步限制),exports 将始终为 undefined。是否有任何方法可以让不同扩展主机之间进行通信(例如，它们是否可以互相调用已注册的命令，因为无论如何这些命令都是异步的)?

是的，不同扩展主机之间的扩展可以使用命令进行相互通信。但是，参数和返回值必须是原始类型或可转换为JSON的类型。

@jrieken 完美，谢谢！

感谢您关注此问题！
我们的SemanticDiff插件需要支持此功能以正确支持Dev容器。为了实现语法高亮，我们目前通过扩展枚举语法和主题。然而，在运行开发容器时，特别是vscode.*内置扩展不可用。
当使用allAcrossExtensionHosts属性而不是all时，一切正常，因此期待此建议得到接受。

我对支持通过导出进行扩展通信的时机很感兴趣。我们在codeflow中遇到了这个限制。

自2022年4月起，此API已标记为api-finalization - 我们是否可以采取措施帮助完成API的最终确定？

就API的反馈而言，我们已经在几个扩展中使用了它，API本身似乎没问题，但文档中有几条评论。

目前在vscode.d.ts中的是：

export namespace extensions {

		/**
* Get an extension by its full identifier in the form of: `publisher.name`.
*
* @param extensionId An extension identifier.
* @returns An extension or `undefined`.
*/
		export function getExtension<T = any>(extensionId: string): Extension<T> | undefined;

		/**
* All extensions currently known to the system.
*/
		export const all: readonly Extension<any>[];

		/**
* An event which fires when `extensions.all` changes. This can happen when extensions are
* installed, uninstalled, enabled or disabled.
*/
		export const onDidChange: Event<void>;
	}

.getExtension() 没有提到如果扩展位于不同的扩展主机中，则可能不会返回已安装的扩展。
.all 说：“系统当前已知的所有扩展”，这是不正确的，即使有了提议的API,因为(根据这个FR)你需要调用.allAcrossExtensionHosts ,才能获取其他主机上的扩展。
名称.all 也不理想，但我确实理解为什么不能为了向后兼容而更改它。(尽管在这种情况下，最初允许多个扩展主机可能是一个破坏性的变化？)

还不清楚.all 是否会包括不在扩展主机中运行的扩展，例如语言扩展。我的理解是它会，但我认为这个文档字符串应该明确指出.all 包括什么。
一旦此API最终确定，事件onDidChange 可能有点模糊，它是否会在其他主机上触发更改？

总结：即使我们不完成API的最终确定，我认为vscode.d.ts中的当前文档字符串应该更新，因为它们没有清楚地说明API将返回什么。