--- name: dependabit-plugins description: "Documentation site for dependabit Use when: Managing a set of plugins across the lifetime of an application.." --- # @dependabit/plugins Documentation site for dependabit ## When to Use **Use this skill when:** - Managing a set of plugins across the lifetime of an application. → use `PluginRegistry` - Isolating plugins in a test suite (via createPluginRegistry). → use `PluginRegistry` - Loading plugins from dynamic imports, configuration-driven plugin lists, or test fixtures where you want to confirm a plugin satisfies the contract before registering it. → use `PluginLoader` **Do NOT use when:** - Using the `globalRegistry` singleton directly in tests that run in parallel — mutations to the global registry leak between test cases. (`PluginRegistry`) - You control the plugin class directly and prefer to call `new` and `initialize` manually — the overhead of `validatePlugin` is minimal but the extra abstraction may be unnecessary. (`PluginLoader`) API surface: 6 functions, 2 classes, 3 types, 2 constants ## NEVER - **Silent collision override is intentional by design in the old API**; the current implementation *throws* on collision. Do not assume `register` is idempotent. - **`clear` is fire-and-forget**: errors from `plugin.destroy()` are caught and logged but not re-thrown. A plugin that fails to tear down cleanly will leave resources open silently. - `load` calls `initialize` if `autoInitialize` is `true`. If `initialize` throws, the plugin is **not** registered — but if the caller has already called `PluginRegistry.register`, the registry will hold a broken plugin instance. Always call `load` **before** `register`. - `instantiate` creates a new instance and calls `load`; the returned instance is fully initialised. Calling `new PluginClass()` directly and registering without going through the loader bypasses metadata validation. ## Configuration **PluginLoaderConfig** — Configuration for the PluginLoader. (2 options — see references/config.md) **Pitfalls:** - Setting `autoInitialize: false` skips calling `plugin.initialize()` on load. Plugins that allocate resources in `initialize` will be unusable until the caller manually invokes `plugin.initialize()`. ## Quick Reference **registry:** `createPluginRegistry` (Create a new, isolated plugin registry instance), `registerPlugin` (Register a plugin to the global registry), `getPlugin` (Get a plugin from the global registry), `listPlugins` (List all plugins in the global registry), `discoverAccessMethods` (Discover available access methods), `globalRegistry` (Global plugin registry instance) **loader:** `createPluginLoader` (Create a plugin loader) **Plugins:** `PluginRegistry` (Registry that maps access method identifiers to plugin instances), `PluginLoader` (Validates and optionally initialises plugin instances before they are registered), `PluginMetadata` (Validated plugin metadata type), `Plugin` (Contract that all dependabit plugins must satisfy), `PluginCheckResult` (The result returned by Plugin), `PluginMetadataSchema` (Zod schema for validating plugin metadata at load time) ## References Load these on demand — do NOT read all at once: - When calling any function → read `references/functions.md` for full signatures, parameters, and return types - When using a class → read `references/classes/` for properties, methods, and inheritance - When defining typed variables or function parameters → read `references/types.md` - When using exported constants → read `references/variables.md` - When configuring options → read `references/config.md` for all settings and defaults ## Links - Author: Pradeep Mouli (https://github.com/pradeepmouli)