Greptile Summary

This PR adds a self-update capability to the CLI, allowing users to run packmind-cli update to upgrade to the latest version. The implementation intelligently detects the installation method (standalone executable vs npm package) and uses the appropriate update mechanism.

Key improvements from previous review feedback:

• Added semver dependency to package.json for proper version comparison
• All interfaces properly prefixed with I following TypeScript code standards
• Version comparison now uses semver.gt() instead of string equality
• GitHub releases explicitly sorted with semver.rcompare()

Implementation highlights:

• Safety guards prevent updates when running via JS runtime (node/bun/deno) with helpful error messages
• Detects local npm packages and shows appropriate update instructions
• Atomic file replacement for executable mode prevents corruption
• Comprehensive error handling with permission-denied suggestions
• --check flag for CI/CD integration with proper exit codes (0=up-to-date, 1=update available)
• File size validation prevents incomplete downloads
• Cross-platform support for macOS, Linux, and Windows

All previously flagged issues have been addressed, and the implementation includes thorough test coverage.

Confidence Score: 5/5

• This PR is safe to merge with no blocking issues
• All previously identified issues have been resolved (semver dependency added, proper version comparison, interface naming conventions). The implementation includes comprehensive test coverage, robust error handling, safety guards, and follows established code standards. The feature is well-scoped with clear separation of concerns.
• No files require special attention

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    Start([User runs update command]) --> CheckRuntime{Running via<br/>JS runtime?}
    CheckRuntime -->|Yes - Local npm| LocalMsg[Show: update via<br/>npm update]
    CheckRuntime -->|Yes - Global| GlobalMsg[Show: use standalone<br/>or npm install -g]
    LocalMsg --> Exit1[Exit 1]
    GlobalMsg --> Exit1
    CheckRuntime -->|No| DetectMode{Executable<br/>or npm?}
    DetectMode -->|Executable| FetchGH[Fetch latest from<br/>GitHub releases]
    DetectMode -->|npm| FetchNpm[Fetch latest from<br/>npm registry]
    FetchGH --> Validate[Filter & sort<br/>valid semver]
    FetchNpm --> Compare{Latest ><br/>Current?}
    Validate --> Compare
    Compare -->|No| UpToDate[Already up to date]
    UpToDate --> Exit0[Exit 0]
    Compare -->|Yes| CheckOnly{--check<br/>flag?}
    CheckOnly -->|Yes| ShowUpdate[Show available<br/>update]
    ShowUpdate --> Exit1
    CheckOnly -->|No| UpdateType{Update<br/>method?}
    UpdateType -->|Executable| Download[Download binary<br/>to temp file]
    Download --> AtomicReplace[Atomic rename<br/>over current]
    AtomicReplace --> SetPerms[Set executable<br/>permissions]
    SetPerms --> Success[Update successful]
    UpdateType -->|npm| RunNpm[Run npm install -g]
    RunNpm --> Success
    Success --> Exit0

_{Last reviewed commit: f10cfad}

@greptile thoughts on the "--check-update" flag?

Looking at the implementation, the --check-update flag is solid and useful. Here are my thoughts:

What works well:

• Non-destructive checking before committing to an update
• Good for automation/CI scripts that want to detect outdated installations
• Clean exit without side effects when flag is present

Suggestions:

1. Consider shorter flag name: --check is more conventional than --check-update. Compare:

   • ✅ packmind-cli update --check
   • vs packmind-cli update --check-update (redundant?)

2. Add exit codes: When running in check-only mode, consider:

   • Exit 0: Already up-to-date
   • Exit 1: Update available
   • This makes it easy to use in scripts: if packmind-cli update --check; then ...

3. Consider alternative: separate subcommand: Some CLIs use update check vs update install, but for this use case the flag approach is fine.

The implementation in updateHandler.ts handles it cleanly:

if (deps.checkOnly) {
  return;  // Exit after logging version comparison
}

Overall, it's a good addition. The only change I'd strongly recommend is shortening the flag to just --check.

Looking at the implementation, the --check-update flag is solid and useful. Here are my thoughts:

What works well:

• Non-destructive checking before committing to an update
• Good for automation/CI scripts that want to detect outdated installations
• Clean exit without side effects when flag is present

Suggestions:

1. Consider shorter flag name: --check is more conventional than --check-update. Compare:

   • ✅ packmind-cli update --check
   • vs packmind-cli update --check-update (redundant?)

2. Add exit codes: When running in check-only mode, consider:

   • Exit 0: Already up-to-date
   • Exit 1: Update available
   • This makes it easy to use in scripts: if packmind-cli update --check; then ...

3. Consider alternative: separate subcommand: Some CLIs use update check vs update install, but for this use case the flag approach is fine.

The implementation in updateHandler.ts handles it cleanly:

if (deps.checkOnly) {
  return;  // Exit after logging version comparison
}

Overall, it's a good addition. The only change I'd strongly recommend is shortening the flag to just --check.

@greptile can you report on the updated version?

Great news! Both of your key suggestions have been implemented:

✅ Changes Made

1. Flag shortened to --check

check: flag({
  long: 'check',
  description: 'Only check if a newer version is available without performing the update',
}),

Usage is now: packmind-cli update --check

2. Exit codes implemented
From the updateHandler implementation:

• Exit 0: When already up-to-date (implicit return)
• Exit 1: When update is available (explicit process.exit(1))

This makes it script-friendly:

if packmind-cli update --check; then
  echo "Up to date!"
else
  echo "Update available"
fi

The implementation is clean and follows the conventional pattern you recommended. The handler checks the version, logs the result, and exits appropriately in check-only mode before attempting any actual update.

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud