-
-
Notifications
You must be signed in to change notification settings - Fork 439
feature: Allow drop-in replacements for svgoΒ #1025
Description
π 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) => stringpackages/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.