So as I continue on deciding to write my notes on Medium instead of in my little tiny book, I stumbled on to Semantic Versioning. I am meant to be learning React but in being the inquisitive person I am and coding being the indecipherable dark wooded land that it is, I have quickly jumped in, run around, lost my breadcrumbs and marbles and landed in obsessively comparing NPM and Yarn and trying to understand what package-pop-&-lock is. Dammit.
Package-lock.json, are you actually going to talk about it this time? Yeah I will endeavour to get there. Wow, some real commitment there. Shut it you.
So have you heard about SEMANTIC VERSIONING. I hadn’t but I definitely knew what it was after the first two sentences. You haven’t because I don’t write as well as this guy (https://medium.com/coinmonks/everything-you-wanted-to-know-about-package-lock-json-b81911aa8ab8).
In its most simplest, you know how you will see some mess of numbers of versions. Did you know what makes the numbers go up. Ie, if I am making changes to version 2.3.1, should me new release make it 2.3.2, 2.4.0 or 3?
Intuitively you already know. “Well if it is a big ol’ change put the big ol’ number on it”. Thanks, but it is more than that.
Let’s say version number is X.Y.Z:
- X is the major version number — if this changes there will be huge, breaking changes. You will have to adjust your code to be able to work with this new version.
- Y is the minor version number — if this changes there is new function in the package, maybe another ability. Nothing will break, but there are more features you can use if you want it.
- Z is the patch version number — just like the movies, they have released a patch. A bug has been fixed, nothing has changed really in terms of function.
Sweet well I knew all that already.
Yeah you might have or if you are like me you could have… like guessed… but I am not overly comfortable “like guessed” as an answer.
But there is more
Now that we know what defines a number change in versioning, we can specify exactly what version we want.
I want the package that has this functionality, but if there is a patch that is fine.
I could state that I only ever want to use a certain version X.Y.Z, but why? If I pick a certain version and in 5 days it gets a patch, do I want the hole that is not patched in that version in my code? Probably not.
Syntax in package.json
Package.json. Now that sounds scary. Let’s pause, WTF is that.
So when you are using npm (or yarn or similar) as well as getting the package on your device, npm (or yarn or similar) makes a record of what you are using. Why? So that if you send that code to someone else, they will be able to download your code and have a record/list of all the other bits of code you had installed (without you having to remember to write a list) and then have npm (or yarn or similar) install it for you.
It looks a bit like this but with more info:
"name" : "MyAppOrCodeName",
"description" : "Almost always never filled in",
"author" : "Joe Bloggs <Joe@Bloggs.org>",
"dependencies" : 
Dependencies are always blank at the beginning and as you install things through npm (or yarn or similar) it adds them there.
Version control in package.json
This can be done in a variety of ways with syntax. Here are the wants and then what you need:
I want this version only — without any patches or anything. Lock this version in only. Forever.
Okay, cool. Just put the number down and nothing else against the package name in the package.json
"dependencies" : [
"the-package-name-is-here" : "X.Y.Z"
I want this version and any patch version above it.
Okay, that makes sense. You need to write “~X.Y.Z”. We could also do “X.Y.x”
"dependencies" : [
“the-package-name-is-here” : “~X.Y.Z”,
“the-package-name-is-here” : “~1.2.x” ]
I want this version and any other minor version above it
Okay, that is pretty normal. I have seen that a lot.
"dependencies" : [
“the-package-name-is-here” : “^X.Y.Z”
Look here for more: https://docs.npmjs.com/files/package.json
Okay so you know what a package.json is
hint: it is a version-specific shopping list of code you need to install to make the code work on everyone’s computer.
Essentially a package-lock.json ignores your fancy
~ rules. This means any small errors you may have will be present. The code you run will be 100% the same as the person who made it. The package-lock.json is a list of everything they installed, at the same version that they were using.
Why? Well even in patches new/different bugs may rise or behaviour may slightly change. This stops this — provided the APIs haven’t depreciated or anything hasn’t changed outside of this code which it relies on.
Cool, done. That is it.