Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion packages/cli/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@
"@origintrail-official/dkg-publisher": "workspace:*",
"@origintrail-official/dkg-storage": "workspace:*",
"@iarna/toml": "^2.2.5",
"commander": "^13",
"commander": "^15",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Bug: Commander 15 narrows the supported Node 22 range

What's wrong
This dependency bump silently raises the CLI's effective minimum runtime from Node 22+ to Node 22.12+. That breaks users who are following the current documented requirement but are on an earlier Node 22 release.

Example
A user or CI runner on Node 22.10 satisfies the documented Node.js 22+ requirement, but this dependency now resolves to commander@15.0.0, whose package declares node >=22.12.0. With engine enforcement enabled the CLI install fails; without it, the CLI runs on a runtime Commander no longer supports.

Suggested direction
Align the dependency bump with the CLI's public runtime contract: either avoid commander@15 until the project requires Node >=22.12.0 everywhere, or update the package/docs/CI runtime requirement to that exact minimum.

For Agents
Check packages/cli/package.json and the published/runtime Node support policy. Either keep Commander on a version whose engines match the advertised Node 22+ range, or explicitly raise every CLI/runtime contract to Node >=22.12.0 and add an engines field so users get a clear failure. Prove the fix by installing the CLI under the minimum documented Node version and under the intended supported minimum.

Make the new runtime boundary explicit

What's wrong
The dependency bump quietly imports commander 15's Node >=22.12.0 engine requirement, but the published CLI package does not make that runtime boundary explicit. That leaves the supported runtime split across package.json and the lockfile, which makes future dependency maintenance and release decisions harder to reason about.

Example
A maintainer looking only at packages/cli/package.json sees a normal dependency bump, but the lockfile has effectively made the CLI depend on Node >=22.12.0 through commander 15. That runtime boundary is implicit instead of owned by the CLI package metadata.

Suggested direction
If the project is intentionally moving the CLI to Node >=22.12.0, declare that in packages/cli/package.json, and preferably keep the root/package docs aligned. If that is not the intended runtime floor, avoid commander 15 here and use the latest compatible commander version instead.

Confidence note
This is based on package metadata only; if the repository already documents a Node >=22.12 runtime elsewhere, this may just need to be mirrored into the published package metadata.

For Agents
Check packages/cli/package.json and the repo-level runtime policy. Preserve the intended commander version, but either add an explicit engines.node declaration to the published CLI package if Node >=22.12.0 is now required, or keep commander on a version compatible with the existing runtime floor. Verify package metadata/lifecycle commands still install under the supported Node version.

Commander 15 raises the Node floor without validation

What's wrong
The dependency bump changes an externally visible compatibility contract, but the PR does not add validation evidence for the Node versions the repo still advertises. CI on .nvmrc value 22 can pass on a newer Node 22 release while missing install/runtime problems on earlier Node 22 versions.

Example
Run the package install/build and a CLI smoke command such as dkg --help under Node 22.0.0 or 22.11.0. The README says Node 22+ should work, but the bumped dependency declares those versions unsupported, and this PR adds no validation that the CLI still works there or that the support floor moved to 22.12.0.

Suggested direction
Decide whether the CLI now requires Node >=22.12.0. If so, update the advertised prerequisites and package metadata and add/adjust CI to run on that exact floor; if not, add a compatibility smoke test on the lowest supported Node 22 version or keep a Commander version that supports it.

Confidence note
Static review only; I did not run the test suite in the read-only sandbox.

For Agents
Look at packages/cli/package.json, README Node prerequisites, .nvmrc, and CI setup-node configuration. Either preserve Node 22.0+ support with a lowest-supported-Node install/build/CLI smoke lane, or raise the documented/package engine floor to >=22.12.0 and make CI validate that floor explicitly.

"better-sqlite3": "12.11.1",
"ethers": "^6",
"js-yaml": "^4.1.1",
Expand Down
12 changes: 6 additions & 6 deletions pnpm-lock.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading