Documentation
    Preparing search index...

    Class PluginHost

    The standalone §81 host: capabilities in, plugins in, one install call.

    const host = new PluginHost([bindCapability(SOLVER_REGISTRY, registry)]);
    host.add(rapierPlugin).add(ragdollPlugin);
    await host.install();

    Use it when the capabilities a plugin needs are values the application owns and Application cannot reach — a solver registry, a serializer registry, a render graph. ApplicationOptions.plugins (§45, as amended by RFC 0002 Q1) is the convenience for the capabilities the application does own.

    Index
    constructor
    added context installed
    add install provide uninstall
    • get added(): readonly FourPlugin[]

      The plugins added but not yet installed, in add order.

      Returns readonly FourPlugin[]

    • get context(): PluginContext

      The live context, or the sealed one after installation.

      Returns PluginContext

      FourError INVALID_APPLICATION_STATE before PluginHost.install — there is no context until there is an installation, and inventing an empty one would let a caller read plugins as [] and believe it.

    • get installed(): boolean

      Whether PluginHost.install has been called.

      Returns boolean

    • Adds a plugin value — never a URL, never a module specifier, never a name resolved out of a document (§96). Returns this so calls chain.

      Parameters

      Returns this

      FourError INVALID_APPLICATION_STATE after PluginHost.install.

    • Resolves order, checks ranges, then awaits each install in order (§81).

      Called once. Re-installation and hot reload are deferred by RFC 0002, so a second call is refused rather than quietly installing nothing.

      Returns Promise<void>

    • Adds a capability this host provides. Returns this so calls chain.

      Type Parameters

      • T

      Parameters

      Returns this

      FourError INVALID_APPLICATION_STATE after PluginHost.install.

    • Removes the installed plugin called name, running its uninstall.

      Uninstall is not symmetric, and this refuses rather than pretending. The registries a capability hands over have different removal stories: SystemRegistry.register returns an idempotent unregister, while registerRenderer/registerSolver offer none and ComponentSerializerRegistry deliberately has no removal at all — a silent overwrite there would make the shape of a document depend on evaluation order. So a capability declares its revocability (DefineCapabilityOptions.revocable, default false), and a plugin that acquired a non-revocable one cannot be uninstalled: this raises naming the capability that pins it, rather than running uninstall and leaving a half-removed registration behind. It is the same contrast rule as removeCollider returning false while addCollider throws.

      Parameters

      • name: string

      Returns void

      FourError INVALID_APPLICATION_STATE when nothing is installed under name, when another installed plugin depends on it, or when a non-revocable capability pins it (§85).

    Settings
    Member Visibility

    On This Page
    Constructors
    Accessors
    Methods