@rugk Your link points to DuckDuckGo...

Uuups… fixed, here is the correct one: https://fedoramagazine.org/design-faster-web-pages-part-2-image-replacement/

Well, I'd say this claim is correct. I'm doing some things (mostly bugfixing) from time to time, but have a little time to develop.

Invite some new maintainers/collaborators on board? Seems plenty of people are keen to contribute.

Not many people are really interested in it, unfortunately.

⭐️ 10,000+ stars on GitHub, surely there is.

@GreLI, you could start by putting someone else in charge of a new semi-official repository just for plugins, then you would only have to maintain the core plugins and the API.

This would speed up development of new plugins while keeping the core code safe. You can merge the most popular plugins into the core once the bus have been ironed out in the other repo.

Plugins is the least of problems. A major rewriting is needed to get significant improvement and to fix some issues.

@GreLI, could you link to the relevant issues in the tracker, or maybe label them as "priority", or apply a milestone, or something like that? It would be good to have some idea what needs doing.

It's just ideas, not really specified. Some pieces of them can be seen here or there. Some quick thaughts:

1. Better parser. Currently sax-js is used, but it has limitations. E.g. some work is needed to preserve white-space (with xml-preserve or white-space style). Also, parse path data syntax, styles, etc. Perhaps lazy.
2. Better plugins system. Now it works consequently and therefore have issues with order of execution. E.g. some plugin is best to run after another in some case, and with directly opposite order in another. Could be event driven (e.g. collapseGroups may execute as soon as there is some <g> without attributes after some transformations).
3. Plugin system should work not only on elements, but with path data.
4. Some better API. E.g. quick check for next node in path data regardless of whether there a start or end of path.
5. It would be nice to have CSS object tree along with document tree for styling checks. E.g. not every transformation can be applied in presence of strokes.

Also, could be cool if core automatically apply every action to check whether it efficient or should be reverted.

@GreLI, the tool you have created is already very good (the best one I know of, in fact) so don't go tearing everything up and starting from scratch!

1. Don't bother with this; it was a mistake to include whitespace preservation in the XML specification. If somebody finds a library that handles whitespace preservation (most don't and for good reason) then they are welcome to implement this, but otherwise don't bother.

   • Whitespace preservation is a relic due to XML's origins as a markup language like HTML, but has it has no place in a data serialization format, which is what XML is mainly used for these days.
   • The main issue is that whitespace is sometimes considered semantic (i.e. part of the data) and sometimes not (i.e. just fancy indentation to make it easy to read). If it was always one or the other it would be fine, but both is unacceptable.
   • Side note: SVG's <tspan> element exists mainly as a way to avoid having to use whitespace preservation in the first place.

2. An event-driven plugin system would be nice, but probably requires a major rewrite. It might be worth experimenting with on a separate branch, but no need to throw away the current system just yet as it works very well in most cases.

3. I don't think the current API handles any path data (maybe just a few things?) so all path manipulations are left to the plugins. I can see why path features would be nice to have, but you could just as easily argue that it is out-of-scope. Why not let somebody else create a path manipulation API and then you can add it as a submodule or something like that?

4. Same as 3.

5. Again, this would be nice but it is starting to sound like you want to just write a whole SVG manipulation library rather than focussing on optimizations that are simple and safe. (And anyway, surely there is already a library you could use?)

6. (automatic efficiency checks) This probably isn't too hard to do.

You already said you don't have time to properly maintain it as it is, so maybe your priority should be to implement features that reduce your workload, not increase it 😉 If you simply allowed plugins to be loaded from outside the project folder that would at least allow plugin to development to continue without requiring input from you, which would leave you free to work on the API.

Might you consider giving somebody else commit access to the main repository? Or you could give the person access to a side repository for plugins, or something like that. (I'm also too busy to get involved, in case you were wondering, but I might be able to help you find somebody who would be interested.)

If you are truly unable to carry on then you need to put some kind of notice in the README and GitHub project description because it's not fair to let people carry on submitting issues and PRs that go unnoticed.

@shoogle: Using jsdom would probably also get rid of many redundancies like the code introduced by the inlineStyles plugin. There should be an object tree by jsdom or at least some library that can run on top of it.

@GreLI could we start with the following:

• Closing old issues and prs. I'd close everything older than 2 years. For the rest I'd manually go through it triaging it.
• Granting access to interested developers: maybe those active in issues and prs in the last 6 months.
• Remove support for EOL node versions.

@GreLI it'd be great to have a definitive answer, either:

• whether you would accept any external maintainers. I think this is the best course of action given the adoption of the project.
• whether this project is no longer maintained. I think it is fair as people are still submitting PRs and is being depended by more than 2 million projects.

@strarsis, @shoogle, @justrhysism would you be interested on collaborating as maintainers?

@sk-: Yes, I use svgo extensively and contribute from time to time. IMHO I learned enough to be a co-maintainer.

PR for replacing sax with saxes: #1281

I developed a library, alumna/unitflow, to solve situations exactly like GreLi's item # 2.

It's possible to specify an execution sequence for svgo plugins (a "flow") and, if parallelism is desired, through separated flows it's possible to define dependencies between desired plugins on different flows, that will be fully respected in a non-blocking, reactive and asynchronous manner.

Uniflow is made in pure JS, it has 0 dependencies and only 1.3kB, it's 100% tested and it's available both in CommonJS and ESM formats.

It's also possible to define multiple flows programmatically with different combinations of plugins sequence, and check which one provides the best results.

@paulocoghi: That's great, something between native JS and webpack.
Could it also be used in an agnostic way to extract resources inside the SVG file (like inline raster images),
then process these separately, like compressing or saving them as external files,
and then either re-embedding these into the SVGs (inlining or an external reference), so also like gulp?
Because using something like webpack for this would lock svgo completely into webpack and would not allow simple, standalone use.

Could it also be used in an agnostic way to extract resources inside the SVG file (like inline raster images), then process these separately, like compressing or saving them as external files, and then either re-embedding these into the SVGs (inlining or an external reference), so also like gulp?

@strarsis yes, it can be used this way! Like gulp, but much simpler :)

SVGO project is currently looking for new maintainer(s), please see #1320