Before/after hook patterns
Why it matters
Without before/after hook pairs, plugins are limited to one-sided interception. A caching plugin cannot check a cache before a request and store the result after it completes — it can only do one or the other. A metrics plugin cannot measure operation duration. A validation plugin cannot both validate input before a write and sanitize output after. This forces plugin authors to duplicate host internals or wire two separate plugins together, increasing coupling and the surface area for bugs. ISO 25010 maintainability.modularity requires that cross-cutting concerns be implementable without modifying core code.
Severity rationale
Medium because the absence of before/after hook pairs prevents plugins from implementing caching, metrics, and two-phase transformations, limiting the plugin system to superficially useful interception only.
Remediation
Add a paired post-hook for every mutation hook that only has a pre-hook. For patterns that need to share context between pre and post phases, consider a middleware wrapper with a next() call.
// Paired hooks:
await invokeHook('before:save', { entity, context });
const result = await save(entity);
await invokeHook('after:save', { entity, result, context });
// Or wrapper pattern:
async function saveWithHooks(entity: Entity) {
return runMiddleware(entity, savePipeline, async (entity) => {
return await save(entity);
});
}
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 — before/after hook pairs let plugins intercept operations without coupling to host internals
Taxons
History
- 2026-04-18·v1.0.0·Initial import from plugin-extension-architecture·automated