Make optional SDK requirements visible

The PostHog backend provider, a registry module, puts its runtime package next to the factory that uses it:

Selected from backend.exports.ts; surrounding declarations and imports are omitted.

  subjectErasureEffect: posthogSubjectErasureEffect,
  requiredPackages: ['posthog-node'],
  agentCallTraceSinkFactory: (config, logger) =>
    new PostHogAgentCallTraceSink(
      {
        projectApiKey: config.apiKey,
        // PostHog-specific connection detail — owned by the provider, NOT the engine.
        host: config.secrets.host,
        captureContent: config.captureContent,
        sampleRate: config.sampleRate,
      },
      logger,
    ),
};

This is a module fragment, not application configuration. The module’s package depends on posthog-node, so installing it (wildo registry add wildo/providers/posthog) brings the SDK; the declaration lets startup report it when it cannot be resolved where the provider runs. The ingest host is a declared slot of the module, resolved by the engine and passed in config.secrets. The sink lazy-loads the SDK; the engine itself never depends on it. immudb, which ships with the engine, declares immudb-node the same way, as an optional peer an application installs.

Understand the startup check

ExternalProvidersRegistryBackendService.reportMissingProviderRuntimePeers iterates the composed modules’ requiredPackages. It tries resolution from the running application first and the engine module second, avoiding a false missing-package report when the SDK is installed only in the application.

The diagnostic is a warning, not installation or a process-wide refusal. A provider may be declared but never reached in an environment. When the sink is actually constructed, its lazy import and provider-specific failure handling determine whether it is available.

This field is not the complete dependency graph. Some protocols carry an SDK descriptor on their runtime contract, and browser activation has its own optional-peer boundary. Check the actual provider’s requirement and its consumer rather than assuming every dependency appears here.

The declaration therefore has two useful roles: it documents what the provider loads and supplies an actionable startup diagnostic. It does not prove the installed package’s version is compatible or that a real vendor request succeeds.