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.

▲

OJFord a day ago | parent | next [-]

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.

	▲	chrisandchris a day ago \| parent [-]
		> (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).

▲

pixl97 a day ago | parent | prev [-]

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.

	▲	darkwater 9 hours ago \| parent [-]
		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).