feature: Allow drop-in replacements for svgo

[noahbald]

🚀 Feature Proposal

Hey there, I maintain an alternative optimiser to svgo that would run faster and produce more correct results. If users could provide a config like below for drop-in replacements, that would be useful!

Motivation

This would allow users to opt into alternative SVG processors at their own discretion.

Example

import { optimise, convertSvgoConfig } from "@oxvg/napi"

// ...
svgr({
  svgrOptions: {
    plugins: ["@svgr/plugin-svgo", "@svgr/plugin-jsx"],
    svgo: (svg, config) => optimise(svg, convertSvgoConfig(config)),
    svgoConfig: {
      floatPrecision: 2,
    },
  },
  // ...
});

Suggested changes

packages/core/src/config.ts
-  svgo?: boolean
+  svgo?: boolean | (code: string, config: SvgoConfig) => string

packages/plugin-svgo/src/index.ts
const svgoPlugin: Plugin = (code, config, state) => {
  if (!config.svgo) return code
+  const svgo = typeof config.svgo === "function" ? config.svgo : optimize
  const svgoConfig = getSvgoConfig(config, state)
-  const result = optimize(code, { ...svgoConfig, path: state.filePath })
+  const result = svgo(code, { ...svgoConfig, path: state.filePath })

Pitch

This would be a relatively small change to the SVGR ecosystem itself, yet would allow users use it more extensively if they choose to do so.

A separate package, such as @svgr/plugin-oxvg could be doable too to avoid users depending on both SVGO and their preferred processor. However, this would probably come with a maintenance cost. Another alternative could be to have a generic adaptor package that @svgr/plugin-svgo or @svgr/plugin-oxvg is a thin wrapper around.

[hiSandog]

A pluggable optimizer needs a small stable interface rather than exposing SVGO-specific configuration as if every implementation can translate it. Please define sync/async return shape, diagnostics, source maps, error behavior, cacheability, and how plugin ordering works; optimizer-specific config can live under its adapter. Compatibility tests should ensure existing boolean/SVGO options remain unchanged while a mock replacement receives exactly one SVG per transform.