SVGO Core and Plugin Ecosystem: Ensuring Safe Rollback After Internal Schema Changes

Question

When SVGO updates its internal representation of the SVG tree to accommodate new SVG 2 elements or attributes, plugins that operate on the mutable JavaScript object tree may inadvertently discard fields they do not recognize. The goal is to allow plugins to detect such incompatibility and trigger a safe rollback to the pre‑optimization state without losing newly added SVG data.
Currently SVGO does not provide a snapshot or versioned schema identifier that plugins can consult, and the plugin API leaves each plugin to decide how to handle unknown nodes. Introducing a schema version into the plugin context could enable rollback logic, but it raises questions about compatibility with existing plugins, the overhead of version checks, and whether a fallback mechanism should be built into SVGO core or left to individual plugins.

Should SVGO expose a schema version identifier in the plugin context for plugins to read?
How could plugins use that version to detect incompatibility and initiate a rollback of their changes?
What would be the impact on existing plugins and overall performance if such a version check were added?

Tasadduq Burney · Answer

Confirmed facts
SVGO’s current plugin interface supplies only the mutable SVG AST and the options object; there is no schema version identifier or snapshot exposed to plugins.
Likely explanation and recommended steps

Create a rollback snapshot – before any optimization, SVGO deep‑clones the input SVG AST and stores it internally.
Inject a schema version – SVGO adds a schemaVersion field (e.g., a monotonic integer or short git hash) to the options object that is passed to every plugin.
Plugin version check – at entry, each plugin compares the received schemaVersion against the version it declares as compatible (could be stored in package.json or a constant). If the versions differ, the plugin:

returns early without modifying the AST, and
sets a flag (e.g., options.rollbackRequested = true) or throws a specific error that SVGO catches.

SVGO rollback handling – if the rollback flag is set, SVGO discards the current (potentially mutated) AST and continues optimization using the pristine snapshot, or returns the original SVG unchanged if no further processing is desired.

Impact on existing plugins and performance

Compatibility – plugins that ignore the new schemaVersion field continue to work unchanged; they simply receive an extra property they do not use.
Performance overhead – the additional cost is a single AST clone (memory proportional to SVG size) plus an integer comparison. For typical SVG files this is negligible; for very large documents the clone may be noticeable and should be evaluated.

Missing diagnostic detail
To finalize the recommendation, we need to know the typical size (in KB or number of nodes) of the SVG files you process with SVGO, as this determines whether the memory overhead of cloning is acceptable in your environment.

SVGO Core and Plugin Ecosystem: Ensuring Safe Rollback After Internal Schema Changes

1 answer

Confirmed facts

Likely explanation and recommended steps

Impact on existing plugins and performance

Missing diagnostic detail

Your perspective belongs here.

0 question comments