DEV Community: Maxime Chéramy

Tools for Semantic Versioning

Maxime Chéramy — Sat, 14 Jan 2023 14:44:49 +0000

Semantic Versioning (also known as SemVer) is a widely-used method of versioning software releases. It uses a version number in the format of X.Y.Z (Major.Minor.Patch), where:

The major version number (X) is incremented when there are breaking changes in the software's API or functionality.
The minor version number (Y) is incremented when new, backwards-compatible features are added.
The patch version number (Z) is incremented for backwards-compatible bug fixes.

Semantic versioning simplifies the work of developers by providing a clear and consistent method for identifying the level of changes in software releases, allowing them to easily assess the potential impact of updating their dependencies and plan accordingly.

In this article I present tools that I use to assist me in managing the versions, publication, and updates of libraries.

Conventional Commits

Conventional Commits is a method of writing commit messages that is also machine-readable. The goal is to make it easier to automate the release process, generate changelogs, etc.

Commit messages written in this format follow a specific structure and contain a prefix (e.g. feat, fix, chore, etc.) that indicates the type of change made. The prefix is followed by a colon and a space, then a short description of the change. An exclamation mark can be used to indicate a breaking change.

This format allows for easy identification of the type of change and its purpose, making it easier for developers to understand the context of a commit and the impact it may have on the codebase.

Another popular commit format is Gitmoji.

Semantic Release

Semantic Release is a tool that automates the process of versioning and publishing of libraries. The versioning follows the principles of Semantic Versioning.

The tool works by analyzing the commit messages in a project's repository, determining the type of changes made (e.g. bug fixes, new features, breaking changes), and automatically generating a new version number and release notes. This is often used in conjunction with Conventional Commits (or the very similar Angular Commit Convention).

It also allows for automated publishing of the release to various package managers such as npm, pypi and maven central. I've mainly used it with npm libraries: every time a PR or MR is merged on Github or Gitlab, Semantic Release creates a changelog, a new release with the new version, publishes the library to the registry, etc. I highly recommend it.

Commitizen

When using Semantic Release, you might be faced by an annoying issue: your commit messages weren't following the convention and they were ignored. It could be because of a typo, a missing colon, an unknown type, etc. And this can be very frustrating because the commit won't appear in the changelog, if you can't wait for the next release and you will have to create a dummy commit to force Semantic Release to create a new release.

If you are using the command line to create your commits, one solution is to use Commitizen. Commitizen will provide you with a nice prompt to ask you the type of change, the scope and the message. This way the commit will be well-formatted and this will also help the developers to adopt the convention. Indeed, at the beginning it could be difficult to decide of the correct type for a change (eg. between chore, libs and refactor).

Commitlint

Commitlint is tool that takes commit messages and check that they follow the commit convention that your project uses.

You can configure your CI or your git hooks to check the commit messages.

Renovate

Renovate is a tool that automatically creates pull requests / merge requests to update dependencies to their latest version, it can work with the main package managers. Semantic Versioning will be very helpful here because we can decide to automatically update (and merge if we want) patches, but keep a code review for minor and major updates for example.

The most popular alternative to Renovate is Dependabot. They are very similar in their objectives but I tend to prefer Renovate that I find more flexible.

DIY: I've built a music box for the 2nd x-mas of my son

Maxime Chéramy — Sun, 27 Nov 2022 20:20:18 +0000

For last Christmas, I wanted to offer my son a music box. But I wanted it to be unique so I decided to build it myself.

In this article, I describe the main components, with links to the source code and schematics. It's not a tutorial but it can be useful if you want to do something similar.

Presentation

The music box is an MP3 player with 6 playlists, volume buttons, previous, stop and next buttons.

Here are the components:

ELEGOO nano (4€)
DFPlayer Mini (3.5€)
CQRobot speaker 3 Watt 8 Ohm (4€)
Buttons (11€)
PCB boards + wires kit (10€)
Battery holders (3€)
Wooden box (8€)

The cost of this project is less than 50€, if I don't count my mistakes (2 wooden boxes wasted because the first one was slightly too small, and the second one I drilled a hole on the wrong side).

Electronics

The player is based on an Arduino nano and a DFPlayer Mini.

The buttons are not shown on this schematic but they are connected to the following pins:

volume down: B2
volume up: B3
playlists: B4 to B9
previous: B12
stop: A0

Arduino nano

The Arduino Nano is a small, complete, and breadboard-friendly board based on the ATmega328. I decided to use an Elegoo model, which is compatible but much cheaper.

The board is powered by 6 AA batteries (~9V), and we use the +5V output to power the DFPlayer Mini.

DFPlayer Mini

The DFPlayer Mini is a small MP3 module that can play mp3 files from an SD card or a USB stick. The documentation is available there: https://wiki.dfrobot.com/DFPlayer_Mini_SKU_DFR0299

It is actually challenging to find a legit DFPlayer Mini, the one I received is based on a MH2024K-16SS chip. This means that the firmware is different and the commands are different.

Software

The source code of this project can be found here: https://github.com/MaximeCheramy/BabyMp3Player

To develop on the Arduino, I use PlatformIO.

DFPlayer support

Probably the most difficult part of this project was getting the DFPlayer to work. I accidentally bought a cheap copy based on a different chipset. I thought it was broken but it just behaved differently (no checksums, different codes for commands).

There are several libraries available to control this chipset with an Arduino. I decided to use the DFMiniMp3 library, and in order to make it work with my module, I contributed to the library: https://github.com/Makuna/DFMiniMp3/pull/77

Main program

The logic is quite simple:

Configuration of the Arduino for all the buttons
Configuration of the DFPlayer
In a loop, we read the state of all the buttons.
- If a button is pressed (for at least 50ms), we store the button index in a variable named currentButton
- If no button is pressed (for at least 50ms), we call the buttonUp function with currentButton.
The buttonUp function calls the appropriate function to change the volume, playlist, etc.

The volume level and the current playlist are stored in the EEPROM of the Arduino.

Conclusion

I built this box exactly 1 year ago, I now have some feedback about it.

One of my biggest fear was that it would simply not work properly. Especially because of this fake DFPlayer Mini which doesn't seem as good as the original (missing commands, need to add extra delays). It turns out that this module seems to work fine. However, I have some reliability issues with the battery holders that... don't hold the batteries after a drop. Or faulty contacts (I decided not to show pictures of the inside of the box because I'm too ashamed of my soldering).
The autonomy is good enough, but I didn't implement anything to automatically turn off the board after some inactivity. As a result, if the box isn't switched off, I will have to replace the batteries.

Apart from these minor issues, it works great. I really enjoyed working on this project and my son loves his music box.

Overview of the current and next-gen frontend development tools

Maxime Chéramy — Tue, 08 Nov 2022 23:49:32 +0000

Frontend Tools are moving fast, and it can be hard to keep up! In this article, I will give a short description of Webpack, Rollup, Parcel, Vite, TypeScript, SWC, ESBuild, Babel, Terser, Uglify, ESLint, prettier, Rome tools...

Transpilers/Compilers

The JavaScript language is evolving a lot but in order to support old browsers, we need to make some transformations (for new syntax) or add polyfills/ponyfills to add new functions.

The most popular JavaScript compiler is Babel. It supports the very latest ECMAScript features and it is clearly the most mature JavaScript Compiler available. But, some people started to think that it was too slow...

So here comes SWC and esbuild. These tools claim to be between 10x and 100x faster than Babel. But how?

1st reason: Babel is written in JavaScript, a single-threaded interpreted language. SWC is written in Rust and esbuild is written in Go. By using these languages, it's possible to have a faster code and to heavily use parallelism.
2nd reason: they have been built with performance in mind from the beginning. They use optimized data structures and they don't need to support very old versions of JavaScript.

TypeScript

TypeScript extends JavaScript by adding types to the language. It may looks a bit scary at the beginning because it adds some syntax and you'll have the feeling to develop more slowly at the beginning.
In practice, TypeScript speeds up your development experience by catching errors and providing fixes before you even run your code. Your IDE will offer a much better completion by knowing the type of the objects you're manipulating. For serious projects, I wouldn't go back to JavaScript.

What about the performance? Well, the TS compiler (tsc) is also capable of transforming JS/TS code into ES5 but has similar perf to Babel. It's possible to use SWC, esbuild and Babel for TypeScript but it won't check your types. However, it's possible to use these tools and do the type checking with tsc.

Linters and Formatters

I think it's a good transition to speak about ESLint. ESLint is a linter that helps identifying and fixing potential issues with your code. It can be formatting issues but it can also be used to enforce some rules to avoid potential bugs.

ESLint is often compared to prettier because it can be used as a code formatter: you define formatting rules and then use the autofix feature to correct the code, when possible. However prettier has a different approach: you set formatting options and it gets rid of the original styling and reformats everything. It's possible to use prettier to format the code and ESLint to enforce other coding rules! It's actually the most popular option nowadays.

Guess what, people also started to complain that ESLint and Prettier were too slow on big projects. And the new kid in town is Rome Tools. Rome Tools ambitions to be a linter, formatter, bundler, etc. For now, only the Linter and Formatter seems to be usable and clearly the project is a bit too young to be used on production projects. But I've tested their Linter on a big project and for the comparison, ESLint takes almost a minute while Rome takes less than a second. The comparison isn't entirely fair because the lint rules were different though, but it's still impressive.

If during Code Reviews, people make comments on the formatting, please consider setting up a formatting tool such as prettier instead. Same for the lint. Code review should focus on code readability, design, complexity, tests, etc. But anything that can be automated should be.

Minifiers

Before we move on to Frontend Bundlers, a quick word about minifiers. A JS minifier reduces the code length by removing unnecessary code (comments, block delimiters, variables too long, etc.) without altering its functionality. The main goal is to make the website load faster.

There are many minifiers such as terser and uglify. But, because minifying also require to parse the JS, it is actually possible to use esbuild and SWC to minify the code. Here's a benchmark of the main minifiers.

Bundlers and Dev Servers

Let's now talk about the frontend build tools, which are meant to make your life easier during development but also to generate the build artifacts that you will host somewhere. I will cover the following tools: Webpack, Rollup, Parcel, esbuild, Vite and Turbopack.

The most popular bundler is Webpack. It is highly customizable, it will bundle your JS files but also your other assets using loaders (CSS, images, etc.), do some tree-shaking and minify everything. It's also a dev server: during the development, you’ll have access to a webserver with HMR and source-map. Webpack is full of features, but the configuration is a bit complex and it's a bit slow. Tools such as Create React App (for React projects) can help to start with a pre-configured webpack configuration.

Rollup is focusing on the bundling part and has a different approach. This article is already big, so here’s a good article on the subject. The tldr is: "Use webpack for apps, and Rollup for libraries".

Parcel is meant to be a zero configuration web application bundler. It has a dev server with hot-reload and everything. This should work great for most projects, I recommend you give it a try. Oh, and it’s based on SWC, so it’s fast!

esbuild is not only a compiler but also a bundler with tree-shaking, source-map, minification, etc. However, this project is young and esbuild is mainly used for the compilation, for now.

More recently, Vercel announced Turbopack. Behind it we can find the creator of Webpack, so it's clearly a serious candidate. And their secret for being faster is also to use tools developed in Rust.

And now, let’s talk about the no-bundlers solutions. I've presented you several bundlers, but I haven't told you why we need them. We need to bundle for production builds when we want tree-shaking, lazy-loading, chunk splitting and support of old browsers... But do we really need to bundle the app during the development phase?

Vite is an ESM-based dev server. The idea is simple: modern browsers now support ESM, so we can actually serve the modules directly to the browser without bundling!

Vite will compile the code using esbuild and they are able to bundle your app using rollup. Even though esbuild could also bundle the app, they decided not to use it.

Conclusion

As you can see, there are many new tools coming up and it's very exciting to see how fast they are. Nevertheless, I would still recommend using tools such as Babel, TSC, Webpack, ESLint and Prettier for most projects. The reason is that they are stable and full of features. Even though they are a bit slow, they do the job.

I've experimented most of the tools I'm describing on side-projects or as a replacement in projects I have at work. I'm impressed by their speed, but I also realized that the time needed to bundle an app isn't only the time needed to transpile the code. I've tested using SWC instead of Babel in a project that takes 5 minutes to be built. Turns out, most of the time was actually spent compressing images through webpack loaders. Using caches was way more efficient.

I know, I've presented a ton of exciting new tools and my conclusion is that they shouldn't be used yet. Let me be clear, frontend tools are evolving so fast that this advice will be deprecated in 6 months. So, follow these tools and watch their adoption and change logs.