feat(convertColors): add excludeMulticolor option to exclude multicolor icons

[chip-cmyk]

Description

When using the convertColors plugin with currentColor configuration, I found that multi-color icons were also being converted to currentColor, making them appear as single-color in actual use. I wanted to preserve the colors of multi-color icons while only converting single-color icons to currentColor. I discovered issue #1302 describing the same problem, so I tried adding parameter configuration to differentiate between multi-color and single-color icons.

New Parameters

• value: Specifies target colors for conversion (boolean, string, or RegExp)
• excludeMulticolor: When set to true, excludes conversion on multi-color and gradient icons

Usage Examples

// Convert all colors, but exclude multi-color icons
{ currentColor: { excludeMulticolor: true } }

// Convert only red colors, but exclude multi-color icons
{ currentColor: { value: 'red', excludeMulticolor: true } }

[SethFalco]

Hey hey!

Thanks for contributing this! Before I review it, would you be willing to chime in on #1673?

I was actually thinking about freezing/deprecating the currentColor parameter on convertColors because this is not an optimization, but rather an editorial decision, and tends to yield unexpected results for most users.

Usually making editorial decisions in this way isn't going to yield desirable results, it's just an inefficient and less predictable way to amend the source, with longer iterations between changes.

I was learning towards deprecating instead of expanding the options to support more use cases, because so far, no one has offered more insight on why we should keep this. The reason it was added (it was hard to override colors in CSS in some clients) is no longer applicable either.

As SVGO is not an SVG editing tool, I think I'd rather keep things simple, and direct users to either hand-edit their SVG, use an actual editor, use an XML library, or a custom SVGO plugin. I wouldn't mind even writing blog-esk guides for this on our website. But I don't think SVGO should support scenarios like this.

I'd love more insight though, if you believe that using this SVGO plugin is actually better than doing it in your vector editor or by hand-editing it, feel free to share!

TL;DR: Imo, rather than adding more maintenance/complexity to the currentColor option, users should be encouraged to fix their SVG. Not make editorial decisions via an SVG optimization tool. Especially as the only way to define the config you've proposed, is by reading the SVG code already, it would've been faster and better to edit the source, right?

[chip-cmyk]

Thank you for the detailed explanation! I've read #1673 regarding the potential issues with currentColorconversion, and I fully understand your intention to keep SVGO's core functionality clean and simple.

In our project, this feature has been very helpful in solving a specific problem. We're working with many Figma-exported icons that need to adapt to different themes through CSS color control, similar to text styling. At first, I found that setting fill="currentColor"via CSS wasn't taking effect because the exported SVGs contain their own fill and stroke attributes. As developers with only view permissions on the design files ,manually editing all these Figma-exported icons would be difficult and time-consuming.

I've tried other approaches like using removeAttrsto remove fill/stroke attributes or Figma SVG export plugins, but they don't handle special cases like fill="none"or mask elements well. The currentColorconversion has worked better for our needs.

If you still prefer to remove this feature, I completely understand. Could you share your thoughts on alternative approach for similar requirements? Before submitting this PR, I actually implemented similar functionality through a custom SVGO plugin. However, I found it difficult to access some internal methods like includesUrlReference. Making more of these utilities available could be helpful for developers creating custom plugins.