[RFC] Plugin/Extension System

[Evanion]

Overview

As NexusDI grows, there is a need for a flexible, robust, and minimal plugin/extension system that allows users and the community to add features, integrations, and advanced behaviors without bloating the core. The goal is to provide a simple, familiar API for registering plugins, inspired by popular frameworks (Express, Fastify, Koa, etc.), while keeping the core lightweight and unopinionated.

Motivation

• Extensibility: Allow users and the community to add features (e.g., logging, monitoring, validation, custom providers) without modifying the core.
• Minimalism: Keep the core small and focused, with advanced features opt-in via plugins.
• Familiarity: Use a use() method, a well-known pattern in the JavaScript/TypeScript ecosystem.
• Ecosystem: Encourage a healthy ecosystem of official and community plugins.

Proposed Features

• Add a use() method to the container for registering plugins/extensions.
• Plugins are functions that receive the container instance and optional options/config.
• Plugins can:
  • Register providers/services
  • Add hooks, event listeners, or lifecycle logic
  • Patch or extend the container instance
  • Integrate with external libraries or frameworks
  • Run initialization or side-effectful code
• Plugins can be composed and registered in any order.
• Plugins can be published as standalone packages or local modules.

Example Usage

// Example plugin
export function LoggerPlugin(container, options) {
  container.set('LOGGER', { useValue: options.logger });
  // Add hooks, event listeners, etc.
}

// Registering a plugin
import { LoggerPlugin } from './plugins/logger';
container.use(LoggerPlugin, { logger: console });

// Multiple plugins
container.use(AuthPlugin, { strategies: [...] });
container.use(OpenAPIModule, { spec: './openapi.yaml' });

API Design

• container.use(plugin, ...args) — Registers a plugin function with the container.
• Plugins are called with the container as the first argument, followed by any additional options.
• Plugins can return a cleanup function (optional) for teardown logic.

Distinction: Modules vs Plugins

Use Case	Module	Plugin (use())
Registering providers/services	✅	✅
Grouping related providers	✅
Declarative dependency graph	✅
Dynamic/conditional registration		✅
Adding container methods/hooks		✅
Running side effects/init code		✅
Integrating with external libs		✅
Community plugin ecosystem		✅

• Modules: For static, declarative registration of providers and dependencies.
• Plugins via use(): For dynamic, programmatic, and side-effectful extensions.

Open Questions

• Should plugins be able to return a cleanup function for teardown?
• Should we provide a plugin registry or discovery mechanism?
• How should plugin errors be handled (fail fast, warn, etc.)?
• Should plugins be able to declare dependencies on other plugins?
• Any conventions for plugin naming, documentation, or versioning?

Call for Feedback

• What features or patterns do you want in a plugin system?
• Any pain points with plugin systems in other frameworks?
• Should plugins be able to modify the container instance directly?
• Would you use or contribute community plugins?
• Any other features or conventions you’d want?