Don’t trust SemVersioning in NPM Modules

Problem

{
“dependencies": {
"some_module": "^0.3.8",
"some_other_module": "~0.1.3",
"dont_do_this": "*"
}
}

Do any of those patterns look familiar to you? Yes? Then I sure hope you know whether all of your installed packages follow semantic versioning (semver)! Otherwise these could be ticking time bombs waiting to blow up in your future deployment.
Some packages follow semver better than others, but, from my experience, the ones you should be most cautious with are the sub-1.0 packages because they definitely don’t follow semver; they typically use the second digit (0.x) as the major version and the third digit (0.1.x) as the patch or feature version! So the next time you run your build for a package in version 0.x you might be in for a nasty surprise.
For a more concrete example, let’s use knex, which is currently in version 0.16.3. Now, if you specify in your package.json to install version 0.x, then this means that the next time you run a deployment you could be installing version 0.17.0, which might contain breaking changes that impact your app!

Solution

At this point, you might be wondering how you could solve this problem. Luckily for us, the solution is pretty simple: lock down all of package versions! Your package.json should look more like the one below to avoid any surprises.
{
"dependencies": {
"some_module": "0.3.8",
"some_other_module": "0.1.3",
}
}

Of course, you can also relax the rules for any packages that you know follow semver. For instance, you’re probably safe to trust packages like react (v16.8.2) and restify (v7.7.0) since they’re both pretty popular projects with many major releases.

Link: https://dev.to//henryjw/dont-trust-semversioning-in-npm-modules-3f2m