If you've found a bug with SVGO, create an issue on GitHub.
Your issue should ideally contain:
- A concise description of the bug.
- How you were using SVGO, the version of the tool, and any configuration or command-line options.
- The SVG that was effected, or a Minimal, Reproducible Example.
If you haven't found a bug, but need help using SVGO in your project, please consider asking on Stack Overflow with the [svgo]
tag, you may get help faster there. You can still create an issue if the confusion stemmed from a lack of documentation.
See: SECURITY.md
- Git
- Node.js 20 or later
Clone the repository with Git.
git clone https://github.com/svg/svgo.git
As this is a Node.js project and uses Yarn for package management, install the dependencies.
yarn install
Finally, make sure all quality assurance checks pass before making changes. This will lint, build, and test the project.
yarn run qa
SVGO uses a plugin architecture, so we ultimately perform many smaller tasks rather than a single monolithic task. This provides users a lot of flexibility for which optimizations they use, and in what order to run them.
See plugins/**
for the list of existing plugins. This is where you can create new ones.
You should read our Plugin Architecture documentation for the gist of how to create a new plugin. If you've created custom plugins before, it's mostly the same process.
SVGO plugins can optionally have parameters. These can be consumed by the plugin to tailor the behavior.
As types are managed through TypeScript definition files and JSDocs, you must define the parameter types in plugins/plugin-types.d.ts
for built-in plugins. Then you'll have code completion and type checking as you'd expect while editing the plugin if your code editor supports that.
Our documentation is maintained in MDX, which is Markdown with React components. The files are then pulled by svg/svgo.dev to build and deploy the SVGO website.
To preview local changes, follow the steps to run the website locally in svg/svgo.dev.
New plugins, plugin parameters, and notable features should be paired with documentation in the docs/
directory and included in the same pull request.
Sponsoring the project helps keep it sustainable for current maintainers.