@kkdev92/vscode-ext-kit - v4.1.1
    Preparing search index...

    Interface DefineModuleOptions<TUses>

    Options for defineModule.

    interface DefineModuleOptions<TUses extends ServiceMap = Record<never, never>> {
        compatibility?: ModuleCompatibility;
        requires?: ModuleRequirements;
        source?: string;
        uses?: TUses;
    }

    Type Parameters

    Index
    compatibility?: ModuleCompatibility

    Which hosts this Module can run in. A declared hard incompatibility is enforced by runtime preflight; a positive compatibility claim remains metadata and does not replace bundle validation or host tests.

    'unspecified'
    

    What the module needs from the host to work at all. Checked at activation.

    source?: string

    Where this module was declared, for diagnostics.

    A label rather than a required file path: production bundles should not be forced to carry source locations.

    uses?: TUses

    Services merged into commands, hosted services, watchers, views and raw registrations in this Module.

    A module's handlers usually work with the same few things — a notifier, the settings accessor, the display language. Declaring them per handler means repeating the same map dozens of times, and the usual way out is to build one god-object service that bundles them, which hides the real dependencies behind a token that means nothing.

    Declared here they are still explicit, still typed and still checked by preflight; they are just declared once. A handler's own inject is merged on top, and a name in both is rejected at definition time rather than silently shadowed.

    const projects = defineModule(
    'projects',
    { uses: { notify: Notifications, l10n: Localization } },
    (module): undefined => {
    module.commands.handle(Refresh, (context, _args, { notify, l10n }) => {
    void notify.info(l10n.t('Refreshing'));
    });
    return undefined;
    }
    );