The inspiration for this functionality came from carbon.now.sh. The app that enables creation and sharing of amazingly looking code snippets. It is super useful and it definitely changed the way people share code snippets on Twitter.

Release Butler aims to help people share beautiful changelogs with ease!

The stack

The project started as a quick Node hack and simple static website with just the right amount of vanilla JavaScript sprinkled on the top…

I guess some of you are curious about how does it work under the hood.On the Node side, the heavy lifting is done by puppeteer which is best described as…

Puppeteer is a Node library which provides a high-level API to control headless Chrome or Chromium over the DevTools Protocol. It can also be configured to use full (non-headless) Chrome or Chromium — Puppeteer GitHub repository

In contrast to originally chosen webshot (backed by dead PhantomJS💀) Puppeteer proved to be much more up to the tasks at hand. Stuff like injecting custom styles and executing arbitrary scripts on the desired page to make it look perfect before taking a screenshot proved to be very valuable!

A dedicated post about biggest takeaways and lessons learned is coming soon

The biggest pain point

The “quick Node hack” approach to the building of the prototype proved to be quite painful earlier than expected. One week in, the need for refactoring of the most of the services became very obvious. And as many of you have guessed already…

Refactoring of plain old JavaScript without the help of Typescript compiler is just painful

I use Typescript in the most of my projects by default. This small journey to the barbaric past proved that the Typescript is in fact THE WAY to go. I guess I will be migrating to Typescript as soon as I am done with all the marketing stuff 😅

Oh no, repo is undefined after renaming some of the arguments 3 folders away… Wouldn’t happen with Typescript!

Note to self ✍️ — Open source releases and changelogs can be a huge mess

Soon after the start of development of Release Butler it became clear that changelogs come in many, sometimes wildly different formats.

Let’s start with the best case scenario. The projects which use built-in GitHub release functionality. Every release is accessible on the dedicated url which maps to the corresponding git tag. Amazing!

Other projects maintain their own Changelog.md files. The variability here is potentially limitless. Content of the file can be generated by a 3rd party library, by hand or a combination of both. Markup and styles can also vary considerably even in the single Changelog.md file over time. The file also contains whole version history which has to be removed because we’re only interested in the one particular release and the list of potential issues and edge cases goes on and on…

Even though it seems to work for all currently supported projects it is not hard to imagine that some releases may lead to undefined behavior and would need additional tweaking. To summarize…

World would be a much better place if everybody just used built-in GitHub releases functionality

The roadmap

I am happy to say that Release Butler is currently in stage when it can definitely provide value to its users. That being said there is always lots of space for improvement.

More libraries

I am definitely interested in adding more popular open source frameworks and libraries. It may be a bit tricky to strike a good balance between covering all the interesting libraries and not ending up spamming people so feedback is more than welcome!

Themes and formatting improvement

Release Butler currently supports only one theme for generating changelogs. It looks pretty sweet but different people may have different tastes so why not indulge them in the way that suits them the best😉

Promoted libraries

A large number of developers are interested in the most popular frontend frameworks like Angular, React or Vue so it is only natural to include them by default.

On the other hand there are also companies like Atlassian or Salesforce with their own open source initiatives ( think UI frameworks and component libraries ) which are mostly targeted to their specific ecosystems. Promoting releases of similar libraries could be viable under the right conditions.