Setu-TS
    Preparing search index...

    Interface IKernelApplication

    Kernel application extends IApplication with inject() capability.

    interface IKernelApplication {
        diagnostics?: IDiagnosticsSource;
        middleware: IMiddlewareApi;
        router: IRouterApi;
        services: IServiceRegistry;
        fetch(request: Request): Promise<Response>;
        hasPlugin(name: string): boolean;
        inject(request: InjectRequest): Promise<InjectResponse>;
        register(plugin: IPlugin): IApplication;
        start(options?: StartOptions): Promise<void>;
        stop(): Promise<void>;
        unregister(name: string): boolean;
    }

    Hierarchy (View Summary)

    Index
    diagnostics?: IDiagnosticsSource

    Read-only kernel diagnostics reader, present ONLY when the application was created with diagnostics explicitly enabled; the property is absent (and this member reads as undefined) otherwise. Absence creates no collector, metadata mirror, ring buffer, or timer anywhere in the kernel.

    This member is the consumer's whole access path: it is a pull-only reader (snapshot() / read()), never a registry token, never a writer, and never a service to resolve. Reading it can neither execute application code nor mutate application state, and the data it returns is a bounded, frozen projection — see IDiagnosticsSource for the exact contract.

    Optional by contract so a third-party IApplication implementation written before diagnostics existed remains valid without adopting it. (| undefined is explicit for exactOptionalPropertyTypes: an implementation may satisfy this with a getter that answers undefined, which is exactly what the disabled kernel does.)

    0.8.0

    middleware: IMiddlewareApi

    The global middleware pipeline.

    router: IRouterApi

    The application router.

    The application-scoped service registry.

    • Delegates a web-standard Request to the registered IHttpAdapter.fetch. This works regardless of whether start() was called (Cloudflare Workers path: setHandler runs at start() time, fetch works without listen).

      Parameters

      • request: Request

        A web-standard Request

      Returns Promise<Response>

      A web-standard Response

    • Reports whether a plugin carrying this name is pending.

      A pure read — it neither resolves nor constructs anything. It exists so a caller applying several exclusions can validate the whole set BEFORE removing any of them: unregister mutates immediately, so removing as you go leaves earlier exclusions applied when a later name turns out to be misspelled, handing a caller that catches the error a silently altered application.

      Answers against the registered plugin list, which startup does NOT clear — so after start() it still reports true for a plugin that has already run. Its purpose is pre-start() validation, and unregister throws once any plugin has registered, so a later answer is not actionable either way.

      Parameters

      • name: string

        The plugin's name, as declared on IPlugin

      Returns boolean

      true when at least one pending plugin carries that name

      0.6.0

    • Resolves plugins, builds the pipeline and router, and starts the server.

      Parameters

      Returns Promise<void>

      If plugin dependencies are unsatisfied or cyclic, or if no plugin provides the runtime capability

    • Removes a pending plugin by name before the application starts.

      Plugins do not run until start(), so removing one here means its register() — and any eager side effect inside it, such as a database adapter's connect() — never happens at all. That is the one thing overriding a capability cannot do: an override replaces what consumers resolve, after the real plugin has already run.

      Removing a plugin another plugin declares in dependencies is not refused here; start() reports it — naming the dependent plugin and the unsatisfied capability, though not the removed plugin's own name when the two differ (database-plugin provides database).

      Removes every pending plugin carrying the name, not the first. Two may share one — the kernel refuses duplicates at start(), not at register() — and dropping one would leave the other running while the caller was told the name was gone.

      Parameters

      • name: string

        The plugin's name, as declared on IPlugin

      Returns boolean

      true when at least one plugin was removed, false when none carried that name

      If startup has begun — including after a start() that FAILED, since the plugins that ran before the failure cannot be un-run

      const app = createApp();            // the project's own composition root
      app.unregister('database'); // the real adapter never connects
      await app.start();

      0.6.0