Plugin dependency resolution
Why it matters
When Plugin B depends on Plugin A but the host loads plugins alphabetically or in undefined order, Plugin B crashes with a cryptic error whenever its load happens to precede Plugin A's. ISO 25010 maintainability.modularity requires that inter-component dependencies be explicit and resolvable; implicit alphabetical load order is the opposite of this. The failure is also non-deterministic across environments — it may work in development (where plugin directories happen to be in the right order) and fail in production after a deploy changes the filesystem state.
Severity rationale
Low because undeclared plugin dependencies produce ordering-dependent runtime crashes that appear only when load sequence happens to be wrong, making them hard to reproduce and hard to attribute.
Remediation
Support a dependencies field in plugin manifests and topologically sort the load order before initializing any plugin. Circular dependencies should produce an explicit error at startup, not a runtime crash.
function resolveLoadOrder(plugins: PluginManifest[]): PluginManifest[] {
const graph = new Map<string, string[]>();
for (const p of plugins) {
graph.set(p.name, Object.keys(p.dependencies ?? {}));
}
return topologicalSort(graph); // throws on cycles
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Plugin / Extension Architecture Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.modularity — Modularity — explicit dependency declarations enable deterministic load ordering across a plugin graph
Taxons
History
- 2026-04-18·v1.0.0·Initial import from plugin-extension-architecture·automated