[FEATURE REQUEST]: Option to hide SVGs that were optimised by 0%

[ghost]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

When dealing with a huge library of SVGs, it's often difficult to see exactly which icons were optimised in the CLI output and by how much since there are a lot that were optimised by 0%.

Describe the solution you'd like A clear and concise description of what you want to happen.

A new CLI flag and/or config property to hide any SVGs that were optimised by 0% in the output, so only the SVGs that were altered are displayed in the CLI output.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

There is a --quiet flag, but this hides everything. I'd still like to see the SVGs that were optimised.

Additional context Add any other context or screenshots about the feature request here.

[viralcodex]

Hi @SethFalco, would love to work on this one if it is fine. Thanks 😄

[viralcodex]

Hi @SethFalco,

The PR for this feature is open now, you may have a look 😄

Thanks

[GreLI]

Personally, I think that optimizing SVG files in CI generally is a bad idea. You're wasting energy, cpu cycles and time to optimize what is already optimized or can be optimized only once. By hiding SVG that weren't optimized you only hiding the problem instead of solving it. This can be solved by caching or changing your workflow.

[viralcodex]

Personally, I think that optimizing SVG files in CI generally is a bad idea. You're wasting energy, cpu cycles and time to optimize what is already optimized or can be optimized only once. By hiding SVG that weren't optimized you only hiding the problem instead of solving it. This can be solved by caching or changing your workflow.

I think people still use it in CLI, we can't say how and what they will use unfortunately, maybe they have a lot of SVGs in their folder and want to get them to get optimised in a go. It is a good accessibility option for users to have, not something that is really needed but is a good to have.

[SethFalco]

Admittedly, I'm not sure if this is something we should handle on our end either.

I'd like to hear a bit more context before we commit to maintaining another argument for our CLI.

My understanding is that this is for knowing which SVGs were affected when bulk processing. However, the solution to this is usually version control, like Git. I don't see conditional output in SVGO being a practical solution here.

And if one isn't using version control, I think it's a really bad idea to bulk optimize SVGs, unless they're being output to another directory or as part of a build process. (i.e. SVGR/webpack) However, in those cases a human isn't reviewing CLI output, so this obvious won't help with that.

I won't close this immediately, as I'm open to feedback! So I'd appreciate if anyone with more context on this use case could help me understand the benefit.

However, I do think this is better suited to being resolved with external tools. For example:

• Use version control to track changes.
• Or use grep, i.e. svgo ./* | grep -P ' (?!0%)[\d.]+%' -B 2 which only shows files that become smaller.

I also find the request to be a bit oddly worded. At least as a user myself, I wouldn't want to only know which files changed size, I'd want to know which files were modified by SVGO. For example, if SVGO failed to reduce the total number of bytes, yet still made modifications (such as sorting attributes) I wouldn't want that to be hidden.

So (hypothetically) if we set out to implement this, I'd expect the implementation to check if the SVG contents has changed, not only if the size changed.