A better versioning scheme for your React Native modules

In this article, I will tell you about the versioning scheme we use for our React Native modules at Wix.

TL;DR: semver syntax and git commits.

Background

The mobile Wix app is a modular app written in React Native. What does this mean? We have one app and many modules. The app repo is essentially a package.json with modules as dependencies, a few engine configurations, and build scripts. That’s it. By default, for standard builds, it will just use the version marked as GA, saying they’re ready for release.

Get it Done

A module is an independent product unit, it can communicate with other modules. All these modules need a version so the app (package.json) should know which version to install. We are using a library written in-house. It is based on Semantic Versioning (semver) syntax and git commits calculation.

We use a versioning scheme that supports patching — why? Life can be rough, and sometimes we need to create hotfixes. We do that by creating a branch from the previous release of a certain module. By following the state of the project’s git tree, a version is automatically calculated in the following manner:

Major: manually from package.json.

"version": "2.0.0"

Minor: number of commits on the master branch.

Patch: number of commits in <branch> since diverged from master. On the master branch, it will be 0.

So if my version in package.json is 3.0.0 , and I have 1,842 commits in my master branch, and I work on the master branch, I’ll get: 3.1842.0 .

For a custom branch, let’s say my version in package.json is 1.0.0 . I checked out my branch when the master had 687 commits, and I push 3 commits to my branch, I’ll get: 1.687.3 .

Problem

Let’s say two developers are working on the same module, which is pretty reasonable. They both want to fix a bug from the same master version: 1.265.0 . They both pushed one commit. Both of them would get the 1.256.1 version, and that’s bad since you can’t have the same two versions on the npm registry.

Luckily, we can also use the build counter. For example, add the build counter (which is unique) to the version, following the patch version, like this: 1.256.1-build.1435 . I must say that this is an edge case, but still, we needed a solution for that, too.

In conclusion, I would recommend using git for calculating the versions for you. Tag every commit with the version so you could connect your module version to the commit.

Hope you enjoyed it!