Plugins

A plugin is TeamHUD’s unit of extension. It’s a TypeScript class that extends BasePlugin (from the Mythic framework), runs in the main process with full trust, and is loaded at startup. A plugin can register a widget — an overlay UI — but a widget is just one of the things a plugin can provide; the plugin itself is the container.

This is the heavier of the two authoring paths. If all you want is a self-contained panel, a custom widget is faster and needs no plugin.

Lifecycle

The framework drives every plugin through the same ordered lifecycle. You implement the hooks you need (each returns a Promise):

1. configure(options?) — the instance is created; read and validate your options.
2. initialize() — deferred setup (e.g. fetch a renderer bundle’s remote).
3. startup() — runs after all plugins are configured. Do the real work here: register resources, wire IPC, register a widget’s renderer bundle.
4. shutdown() — tear down when the app closes or the plugin is unloaded.

Two event hooks let a plugin react to the wider system: onSystemEvent(event) (runtime lifecycle events like pre/post global startup) and onPluginEvent(name, data) (events emitted by other plugins).

What a plugin declares

A plugin describes itself with info(), which returns metadata: its name and version, the resources it provides (a widget is a resource), dependencies on other plugins, and options. The framework uses this to load, order, and toggle plugins. See the Plugin API reference for the full shape.

A widget plugin is two halves

When a plugin provides an overlay widget, it has two parts:

1. The main-process plugin (extends BasePlugin) — registers where the renderer bundle lives, in startup().
2. The renderer component (extends OverlayHubWidget) — the actual Lit UI.

The Build your first plugin tutorial builds exactly this, end to end. A plugin that isn’t a widget simply skips the renderer half and does its work in the lifecycle hooks.