SVGO plugin rename causes silent failure during optimization

Goal

\n

The objective is to preserve rollback safety when a configuration change triggers a plugin to be silently ignored after a major SVGO upgrade. A missing plugin can alter IDs, viewBox, or other critical attributes, making the output unusable for downstream consumers.

\n

Constraints

\n

SVGO’s configuration schema is version‑sensitive; built‑in plugins are renamed or merged between v2 and v3. The tool performs a one‑way transform without storing the original file, and it offers no built‑in validation of deprecated or unknown plugin names. Users must therefore detect schema drift and keep a backup of the source if a plugin is lost.

\n

Open Questions

\n

\n
• Is there a programmatic way to detect that a plugin name in a config has been renamed or removed in the current SVGO major release?
\n
• What strategy can be adopted to automatically preserve the original SVG for rollback when a configuration change silently alters the output?
\n
• Does SVGO expose a configuration validation API that can be used to pre‑emptively catch unsupported or deprecated plugin names before running optimize()?
\n