Start with defineModule to declare one cohesive feature, then pass those
modules to defineExtension and re-export its activate/deactivate
properties from the extension entry point. Handlers receive an
OperationContext and explicitly declared injected services; tests run the
resulting app.plan with the ./testing entry point. That route preserves
preflight, dependency validation, resource ownership and one shutdown path.
What is deliberately not here is anything that would be a second way to
reach something already exported. defineExtension compiles the plan, builds
every capability and owns the lifecycle, so the application constructors, the
createVSCode*Capability factories, the scope constructors and the host state
machine stay internal — exporting them would offer a second way to start an
application, one that skips the parts the first way guarantees.
The same rule excludes a free function beside every token: showInfo next to
Notifications, createTypedStorage next to defineStorage. Each ability is
reachable exactly once, through a declaration or an injected token, so there
is never a question of which of two spellings is the right one.
Extension-host feature code should import from this barrel. The vscode-free
helpers — ./timing, ./retry,
./format — are also their own subpaths, for a webview bundle, which cannot
import this module at all: it reaches defineExtension and therefore
vscode, which a browser build cannot resolve. Extension-host code should not
have to know that. The test surface is ./testing, and the browser half of
the webview RPC is ./webview-client. The root barrel is intentionally not
browser-safe because it includes defineExtension and therefore the real
vscode adapter.
If the framework does not cover an API, use a module's managed raw
registration and put every registration/resource returned by VS Code into
the supplied scopes. That keeps declared dependencies visible to preflight
and cleanup inside the application lifecycle. A direct vscode import
outside that boundary is invisible to the Test Host and needs its own
Extension Host coverage.
Public extension-host surface of vscode-ext-kit.
Start with
defineModuleto declare one cohesive feature, then pass those modules todefineExtensionand re-export itsactivate/deactivateproperties from the extension entry point. Handlers receive anOperationContextand explicitly declared injected services; tests run the resultingapp.planwith the./testingentry point. That route preserves preflight, dependency validation, resource ownership and one shutdown path.What is deliberately not here is anything that would be a second way to reach something already exported.
defineExtensioncompiles the plan, builds every capability and owns the lifecycle, so the application constructors, thecreateVSCode*Capabilityfactories, the scope constructors and the host state machine stay internal — exporting them would offer a second way to start an application, one that skips the parts the first way guarantees.The same rule excludes a free function beside every token:
showInfonext toNotifications,createTypedStoragenext todefineStorage. Each ability is reachable exactly once, through a declaration or an injected token, so there is never a question of which of two spellings is the right one.Extension-host feature code should import from this barrel. The vscode-free helpers —
./timing,./retry,./format— are also their own subpaths, for a webview bundle, which cannot import this module at all: it reachesdefineExtensionand thereforevscode, which a browser build cannot resolve. Extension-host code should not have to know that. The test surface is./testing, and the browser half of the webview RPC is./webview-client. The root barrel is intentionally not browser-safe because it includesdefineExtensionand therefore the realvscodeadapter.If the framework does not cover an API, use a module's managed raw registration and put every registration/resource returned by VS Code into the supplied scopes. That keeps declared dependencies visible to preflight and cleanup inside the application lifecycle. A direct
vscodeimport outside that boundary is invisible to the Test Host and needs its own Extension Host coverage.