This week I released pug 3.0.0. This release brings a few really exciting new features, as well as a couple of small breaking changes. I also took this opportunity to update the supported versions of node.js to match the official LTS versions. The breaking changes are minimal, and should not impact most users. The highlights include:
- The new
each … of …syntax lets you iterate over Maps and Sets as well as Arrays, and is more efficient than the
each … in …syntax. Don’t worry though, the old syntax is still there, and you do not have to do anything to update if you don’t want to.
- You can now write filters that operate on binary data (e.g. images). This means you can import an image, apply a filter, and output an optimised
<img/>tag with the image data inlined as a base64 string. This can improve page load times, and make your web app easier to deploy.
You can check out the full release notes on GitHub to see examples for these features, as well as a list of the (minimal) breaking changes.
Ever since I merged Pug’s many separate packages into a “mono repo”, I was frustrated by how difficult it was to do a release. There is a lot that I like about Lerna (the tool I was using to manage this mono repo), but releases were extremely error prone, and involved a lot of nail-bitingly tense work to review the commits and decide what version each package should be released as.
The issue here is the loss of context. I wanted to be able to create and manage the release notes and versioning along with the pull requests that contain the features and bug fixes. A colleague at Threads Styling introduced me to semantic-release, which we now use extensively. It lets you generate release notes and automate the release process of a single npm package, based on the commit messages. I’ve really enjoyed using semantic release, but unfortunately I encountered a few limitations:
- Semantic release does not work for mono repos (this was a deal breaker for pug).
- Semantic release requires precisely formatted commit messages. This resulted in some mistakes where releases had the wrong version, or commits did not trigger a release when they should have.
- Semantic release only allows one feature/bug fix/breaking change per commit. This doesn’t work well with how I like to handle pull requests.
For a long time, I’ve felt that the solution to this problem is to attach change logs directly to the pull requests, rather than the commits. For the past 6 months, I’ve been working on creating a solution that does exactly that. Rolling Versions provides a simple user interface to allow you to attach change logs to specific packages in a pull request. It then provides a CLI to publish your packages, which you can run on your continuous integration service (in this case GitHub Actions).
It’s taken a long time to get to this point, but it did finally allow me to release a new version of pug with confidence, and I expect it to enable more frequent releases in the future.
Although I still have a lot of improvements I want to make to Rolling Versions over the coming months, the beta version is now ready for you to use on your projects.