Optional ReadonlydiagnosticsRead-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.)
ReadonlymiddlewareThe global middleware pipeline.
ReadonlyrouterThe application router.
ReadonlyservicesThe 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).
A web-standard Request
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.
The plugin's name, as declared on IPlugin
true when at least one pending plugin carries that name
Synthesizes an incoming request and runs it through the full pipeline without requiring a listening server.
The synthetic request
The inject response
Registers a plugin. Plugins register when the application starts, in dependency order.
The plugin to register
This application, for chaining
Resolves plugins, builds the pipeline and router, and starts the server.
Optionaloptions: StartOptions
Port and hostname
Stops the server and runs shutdown hooks.
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.
The plugin's name, as declared on IPlugin
true when at least one plugin was removed, false when none carried that name
Kernel application extends IApplication with inject() capability.