Looking back at some code that I have written in the past 2-3 months ago, I have realized that there is a huge difference in the way I write code along with file structuring and documentation.
A huge difference like I have been reading other people's code and see how do they get things done, how they structure their applications, along with how they document their code. So, I looked at my old code and refactor some bits of it but I realized that I am still on version 1.0.0 of my application.
this is where the fun part starts
so imagine that you have been working on this project of yours for quite some time, pushing new features and updates just to realize 3 months later that your application is still on version 1.0.0 and who knows how many bug fixes you have fix nor how many features added to this project of yours not to mention if you added something that is not backward compatible so yeah 🤷♀️
And I admit the fact that I am not that of an organized person like sometimes I get carried away with work or tasks that I end up not doing the most basic things like updating your project's version number
the solution: automate it 🤖
This is a weird approach since I just mentioned earlier that I am not that of an organized person yet I found a way to automate this process.....interesting 🤔
Well, you write it once and use it forever plus imagine how much time I will be saving when pushing more than 5 commits and trying to think if this is a feature or a bug fix
semantic versioning
So I started to research about common patterns for version management and see how other developers are handling this issue. What I noticed is that most of them are following a method called semantic versioning (or semver for short) which I found a site that explains it pretty well here also not to forget npm's documentation of semantic versioning as well which can be found here
without getting into details, your version number is made up of 3 numbers which they are: major, minor, and patch
major.minor.patch
example: 1.3.5
the major number is to indicate which major version of this project it is on and when you increase that number, it just indicates that you have submitted a change that is not backward compatible at all (keep in mind that when you shift to an upgraded version number, your minor and patch number is set to zero. Example: shift from version 1.5.7 to 2.0.0)
the minor number is to indicate how many features and additions have been added to this project. It offers backward compatibility as long it is on the same major version number
the patch number is to indicate how many patches and bug fixes have occurred on that major version number
usually how you update your version number?
depends on the developer, since each developer has his/her own way of upgrading their version number.
Some might just update the value by accessing the project's package.json and increment the number, some might create a script that automates the process so when they commit and push changes then it increments the number
pjsv: my own version of this method
in a nutshell, what pjsv does is that it reads your package.json file and gives an interactive menu to update your version number based on what you have chosen by writing to that package.json file
the cool thing about pjsv is that it only updates your package.json file and nothing else. It doesn't push updates using git just updating your version number, giving you full freedom to do what afterward
best practice for pjsv
I would highly recommend using Husky along with pjsv
in your package.json:
"husky": {
"hooks": {
"pre-commit": "pjsv upgrade",
}
}
in this setup every time you write a git commit message, it will upgrade your package.json file then adds it to the commit itself
great! where can I start?
you can start by downloading it as a dev dependency in your project
npm install pjsv -D
it also supports the use of npx if you don't want to install it on your project
npx pjsv upgrade
you can find out more about pjsv on Github
comments, feedback, and contributions are highly appreciated!
Top comments (0)