Skip to content

v4.0.0-rc.4

Pre-release
Pre-release
Compare
Choose a tag to compare
@SethFalco SethFalco released this 06 May 07:29
· 8 commits to main since this release
1deb4a7

Release Candidate

This is a release candidate. We are still working on v4.0.0, and API stability isn't guaranteed, though we'll aim to keep it fairly consistent. You can try this build by installing or depending on svgo@4.0.0-rc.4, or svgo@rc.

Please report any problems you encounter in the GitHub issue tracker. 👍

Refer to the release notes of previous v4.0.0 release candidates to get the full context, this will only describe the differences since the previous release candidate.

We're also working on a Migration Guide from v3 to v4. This will be accessible on svgo.dev once SVGO v4 has been officially released, but currently can only be read from the repository. The migration guide is more concise than the release notes, and only covers the breaking changes.

Changes

Fixes the type declarations for #loadConfig, which were incorrect in v4.0.0-rc.2 and didn't perfectly match previous releases. The types should now behave the same as v3, and we've added stricter tests to enforce this with tsd.

expectType<Promise<Config | null>>(loadConfig());
expectType<Promise<Config | null>>(loadConfig(undefined));
expectType<Promise<Config | null>>(loadConfig(null));
expectType<Promise<Config>>(loadConfig('svgo.config.js'));

Thanks, @ntnyq, who reported this issue and contributed a fix.

Metrics

No functional changes have been made that would affect SVG optimization or the browser bundle.

Why did we skip SVGO v4.0.0-rc.3?

SVGO v4.0.0-rc.3 was accidentally published as a stable release instead of a release candidate. I noticed this within minutes, deprecated that version, and re-assigned the latest dist tag to v3.3.2. Fortunately, the impact should be minimal as most projects pin to major versions, which ^3 does not overlap with v4.0.0-rc.3.

I'm very sorry for any inconvenience this may have caused, though. 🙇

I will discuss this with the other maintainers, to see if I can get the permissions necessary on GitHub to migrate our publishing workflow to GitHub Actions. That should reduce the risk of this from happening again.