Most of Wikimedia projects currently use 'svgo' package in v2.8.0.
With the new 3.x releases there have been minimal changes and numerous optimization (as exposed Typescript types out of box, no need to install '@types/svgo' package anymore
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Volker_E | T324899 Update SVGO to 3.x across all Wikimedia codebases | |||
| Resolved | Volker_E | T324900 Update SVGO to 3.x in Codex | |||
| Resolved | Volker_E | T333155 Update SVGO to 3.x in OOUI | |||
| Resolved | Jdlrobson | T333158 Update SVGO to 3.x in Vector | |||
| Resolved | Volker_E | T339162 Update SVGO to v3.x in various extensions & skins | |||
| Resolved | Volker_E | T339290 Update SVGO to 3.x in MediaWiki core |
@JoKalliauer Just saw your comments on my talk page. This Epic is about updating the build libraries for interface SVGs in Wikimedia deployed products, see for example the subtask T324900. SVGO is in place and has, with our optimization guidelines, not been buggy at all, but helped to reduce the data sent to clients by Gigabytes.
Maybe it is not buggy for the developers since I know only few cases wher SVGo couln't create an "optimized" SVG from a Commons-SVG, however those so called "optimized" SVGs are often broken (=don't render as intended). SVGo already broke too many SVG-files on commons, that's why (SVGo-)Users reuploading "optimized" SVG-files get reproved on commons, see Commons:SVG guideline for details. The damage-rate of any optimizer is way too high, expecially of the default settings of SVGo. Maybe you deactivated the most problematic ones. I just pointed out 6 common SVGo-Bugs for SVG-files on Commons on your talkpage. Can you tell me your settings and I can tell you the relevant bugs relating to those settings (even if you deacitate everything, svgo still breaks files).
Sure, the “WikimediaUI” SVGO preset we've developed and some of the underlying principles are documented at SVG Coding Conventions/Automated optimisation.