Closed opauloh closed 1 year ago
This is a smart idea, but I am concerned about bundling even more dependencies; by the way this uses svgo
as a dev dependency which wouldn't work?
On that note, is svgo
"bundleable" with Webpack?
This is one more thing that could be provided possibly as a guide rather than a feature.
Kudos, SonarCloud Quality Gate passed!
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
On that note, is
svgo
"bundleable" with Webpack?
Hey, yes it should be on 'dependencies' instead of devDependencies
to be "bundleable" by webpack, I just updated the PR
This is a smart idea, but I am concerned about bundling even more dependencies; by the way this uses
svgo
as a dev dependency which wouldn't work?
It's "bundleable", and it significantly increases the package size: from 218 kb to 1.49 MB,
Current:
With SVGO:
On my note, I wasn't so worried about bundle size because Figmagic is a dev dependency and won't get bundled for end users, and on the other side, the SVGs are bundled, and having them optimized by default could make the trade-off worthwhile.
This is one more thing that could be provided possibly as a guide rather than a feature.
That might be a good idea 💡
OK, @opauloh. While I love your work, I feel like this one isn't in line with design goals like keeping this light and dependency-less. It's a bit of a dud that Figmagic uses Webpack at all, but it comes down to bundling all of the files of the project rather than, as is normal, also any third party dependencies. This design goal may not have been clear, but I feel it's the right call—svgo
optimization I am happy to support with a dedicated guide that we can link to in the regular README.
Once again, it's never "fun" saying no, but in this case we retain the clarity of the project while easing production-grade use for our users if we can assist them, but it's not part of Figmagic itself.
Thanks for your kindly anwer @mikaelvesavuori , I agree with you, and realized I had precipitated myself in opened the PR (we could had discussed that on an issue first).
I'll be happy to add an guide on how to optimize svgs later, thanks
Hi everyone
This PR adds a step that optimizes SVGs downloaded from Figma by using the SVGO API.
That ends up benefiting the final users as it helps on reducing bundle sizes and also makes it easier for animations by optimizing the number of paths.
The benefit can already be seen on simple SVGs, but the more complex SVG, the bigger the benefits. The difference is also huge when importing illustrations from Figma.
Example of an SVG downloaded from Figma:
SVG xml:
SVG Image:![Recycle](https://user-images.githubusercontent.com/19270322/197979105-0f22eb38-d6da-48e0-892c-6b3b5e8a2a09.svg)
Example of the same SVG after the optimization:
SVG xml
SVG Image:![Recycle](https://user-images.githubusercontent.com/19270322/197978620-ff926056-2eb9-46b7-82db-9bf69f0331a8.svg)
Final result:
The SVG image remains the same, but the markup is optimized and more readable.
Added the optimization as default but added the
--noOptimizeSVG
CLI option for users to disable the optimization if needed (It can also be disabled by settingoptimizeSVG: false
on thefigmarc
file)Description of the changes made
svgo
and@types/svgo
library on package.jsonoptimizeSVG
option enabled by defaultoptimizeSVGGraphics
functioncreateGraphics
function to calloptimizeSVGGraphics
(only when output isoutputFormatGraphics
issvg
)optimizeSVG
andnoOptimizeSVG
optioncreateGraphics
Checklist