Summary
The compiled CLI bundle reports a stale version. package.json is 0.6.11, but the bundled dist/index.js prints 0.6.9 for --version.
Repro
Global install of the latest published package (patchwork-audit@0.6.11):
$ node -e "console.log(require('patchwork-audit/package.json').version)"
0.6.11
$ node <prefix>/node_modules/patchwork-audit/dist/index.js --version
0.6.9
Impact
- During support/debugging it looks like an older version is installed, even though it's the latest. We burned real time on this: a PreToolUse denial told the user to run
patchwork approve <id>, the bare patchwork on PATH (a separate older shim) lacked approve, and --version reporting 0.6.9 made it look like the wrong binary — when in fact 0.6.11 was correctly installed and did have approve/clear-taint.
- Makes version-pinned bug reports unreliable.
Likely cause
The version string appears to be hardcoded / embedded at build time and isn't refreshed from package.json on release (the bundle predates the version bump).
Suggested fix
Either read the version from package.json at runtime, or inject it as a build-time define sourced from package.json during bundling, so the two can't drift. A CI check (assert dist --version === package.json version) would prevent regressions.
Secondary (minor) UX note
The denial message hint patchwork approve <id> assumes the patchwork on PATH is this version. When an older patchwork shim shadows it, the hint fails confusingly. Consider printing the absolute path/command of the enforcing binary in the denial (e.g. node <abs-path> approve <id>).
Summary
The compiled CLI bundle reports a stale version.
package.jsonis0.6.11, but the bundleddist/index.jsprints0.6.9for--version.Repro
Global install of the latest published package (
patchwork-audit@0.6.11):Impact
patchwork approve <id>, the barepatchworkon PATH (a separate older shim) lackedapprove, and--versionreporting0.6.9made it look like the wrong binary — when in fact0.6.11was correctly installed and did haveapprove/clear-taint.Likely cause
The version string appears to be hardcoded / embedded at build time and isn't refreshed from
package.jsonon release (the bundle predates the version bump).Suggested fix
Either read the version from
package.jsonat runtime, or inject it as a build-time define sourced frompackage.jsonduring bundling, so the two can't drift. A CI check (assert dist --version === package.json version) would prevent regressions.Secondary (minor) UX note
The denial message hint
patchwork approve <id>assumes thepatchworkon PATH is this version. When an olderpatchworkshim shadows it, the hint fails confusingly. Consider printing the absolute path/command of the enforcing binary in the denial (e.g.node <abs-path> approve <id>).