CodeVetter · Repo Unpack · Extension points
microsoft/vscode
VS Code is essentially a registry machine. Internal code plugs in through: (1) registerSingleton for DI services with eager/delayed instantiation; (2) the generic Registry.as() pattern for typed contribution registries; (3) WorkbenchContributionsRegistry keyed by lifecycle phase; (4) registerAction2/MenuId for commands+menus; (5) ConfigurationRegistry for settings schema; (6) ExtensionsRegistry/ExtensionPoint<T> which materializes the 59 declared contribution points in extensionPoints.json. External extensions plug in through package.json contributions plus the `vscode` API built per-extension by createApiFactoryAndRegisterActors, with proposed APIs gated by extensionsApiProposals.
- registerSingleton(id, ctor, InstantiationType.Eager|Delayed) in platform/instantiation/common/extensions.ts is how all shared services register; getSingletonServiceDescriptors() is consumed by Workbench.initServices to seed the ServiceCollection.
- The platform Registry (platform/registry/common/platform.ts) provides the add/as/knows primitive behind every contribution registry; workbench features call Registry.as<...>(SomeExtensionPointId) to contribute.
- ExtensionPoint<T>/ExtensionsRegistry in extensionsRegistry.ts implement package.json contribution points: handlers receive ExtensionPointUserDelta (added/removed) so contributions can hot-update when extensions install/uninstall.
- extensionPoints.json enumerates all 59 supported contribution points — including commands, menus, configuration, grammars, themes, languages, views/viewsContainers, notebooks, customEditors, debuggers, chatAgents/chatParticipants/chatSessions/chatSkills, languageModelTools, mcpServerDefinitionProviders, terminalQuickFixes and walkthroughs.
- Commands and menus are contributed via Action2/registerAction2 and MenuId from platform/actions/common/actions.ts — used inside the workbench itself (e.g., web.main.ts registers actions) as well as surfaced to extensions through the commands/menus extension points.
- Settings schema is an extension point: ConfigurationRegistry (platform/configuration/common/configurationRegistry.ts) accepts 'configuration' contributions which the layered ConfigurationService then resolves across default/policy/user/workspace/folder scopes.
- File system providers are an extension point: IFileService.registerProvider lets extensions (and core) mount arbitrary schemes, and the extension service auto-activates extensions on 'onFileSystem:<scheme>' events.
- The public extension API surface is generated from src/vscode-dts/vscode.d.ts (+ proposed d.ts files, compile-checked by npm run vscode-dts-compile-check) and materialized per-extension by createApiFactoryAndRegisterActors in extHost.api.impl.ts.
- Proposed/unstable APIs are an explicit extension-point gate: extensionsApiProposals.ts maintains allApiProposals which extensionsRegistry consults, and ExtensionsProposedApi enforces enablement per extension/product rules.
- Extension host placement is pluggable: ExtensionHostKind + ExtensionRunningLocationTracker + IExtensionHostKindPicker decide whether an extension runs in the local process host, a web worker host, or on the remote agent.
- Built-in extensions are themselves extension-point consumers: each extensions/*/package.json declares contributes blocks (grammars, themes, languages, commands) loaded through the same ExtensionsRegistry as third-party extensions.
- New IPC surfaces are added by registering channels: Server.registerChannel(name, channel) on ElectronIPCServer/NodeIPCServer/IPCServer — e.g., McpGatewayChannelName and NativeMcpDiscoveryHelperChannelName were added for MCP support.