Shouldn't vulnerabilities be "data" in this context? You bump the vulns database but keep the code at the same version if the logic is the same.
Shouldn't vulnerabilities be "data" in this context? You bump the vulns database but keep the code at the same version if the logic is the same.
If it's baked into the tool (can run offline) then it would be unavoidable, need a new version to get a new release on the package manager.
1.2.3 -> 1.2.3+1 (or +anything, date, whatever) could arguably be idiomatic semver though - that's what you do for packaging changes, like updating the description or categories to file it under etc. without actually changing the program.
> (can run offline)
And yet you need internet access when running the package with npx, even though the package is already locally installed.
At least, I can't use npx on so e of my VMs which do not have access to the internet. It just takes forever to atart (and I get annoyed after some minutes).
The particular problem here is if you started out doing it wrong then changing your update behavior would break everyone's scripting around it. By changing the 'code version' everyones CI/CD system just keeps working the same way as any other package.
I understand, but you can just have a committed config file that tells which definitions version to use and/or URL to retrieve (so you can mirror it on your infra or serve a patched version for your use case).