How to automate a Javascript project versioning
Tags: javascript, codequality, programming
Published: 2020-12-30 17:53:52

Sooner or later all developers need to handle some sort of versioning their software. If you've been there you know that **manual updating** versions, **changelogs**, and **tags** are **prone to error and emotional decisions**.

In this article, I'll try to show an easy and automated way of managing your versions following the [conventional commiting](https://www.conventionalcommits.org/en/v1.0.0/) structure and with the help of [standard-version](https://github.com/conventional-changelog/standard-version).

# Install standard-version

Let us start with installing our package

`npm i standard-version -D`

Now, for the purpose of easiness add the following script to your `package.json`

```
{
  "scripts": {
    "release": "standard-version"
  }
}
```

# How it works

Our package needs us to follow the [Conventional Commits Rules](https://www.conventionalcommits.org/en/v1.0.0/) in the repository. This means that we must use the correct syntax. 

Here is an overview of how it's done:

1. **fix** for a **`PATCH`**
2. **feat** for a **`MINOR`** 
3. **!** scope suffix for a **`MAJOR`** 

So the commits must follow the pattern `scope!: message` the **!** is optional for a **`MAJOR`.**

```
feat: new reset password button` -> 0.1.0
feat!: new reset password button` -> 1.0.0
```

# Workflow

Now that all is configured and we've understood the ground rules for automated versioning, let's have a look at a simplistic view of how a workflow should be.

**Developing a feature on a feature branch**

1. `git add .`
2. `git commit -m "feat: created a reset password"`
3. `git push`

**Merging to the master branch** - *this is where the magic happens*

1. `git merge origin/feature-branch`
2. `npm run standard-version` *- the package is looking into the commit history and automatically increasing your API version to X.Y.Z*
3. `git push —follow-tags origin master` - *this is pushing your bumped with the changelog file and tags generated*

**And that's all!** You should be able to see on your `master` branch the corresponding bumped version with the changelog file and all linked to a tag.

# Common mistake

According the [semver](https://semver.org/) 

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

This means that until you intentionally run `npm run release -- --release-as major` you won't see your major version bumping from **0.y.z** to **1.y.z**. From this moment on, the package will do its job and bump major versions as well.

# Conclusion

Bumping versions based on [conventional commiting](https://www.conventionalcommits.org/en/v1.0.0/) convention of rules is seen as a good practice in order to have an explicit commit history. 
With the help of [standard-version](https://github.com/conventional-changelog/standard-version) we've seen above we are able to automatically bump versions and track changes each time an artifact is released into production.

#####Special thanks to [https://unsplash.com/@csoref](https://unsplash.com/@csoref) for the header image :)