chore: [PR-1797] re-land sf migrate command and Rust CLI migration banner

[sigmachirality]

Summary

Reverts #267 (which reverted #266). Restores the sf migrate subcommand and the legacy-CLI migration banner pointing users at the Rust CLI installer.

Motivation

#267 pulled the banner because the Rust CLI installer at cli.sfcompute.com wasn't actually creating the sf-old fallback the banner advertised. With the installer fix landing, the original UX from #266 is safe to ship again.

No code changes vs #266 — this is a pure git revert of the revert commit (34edddab).

Testing

• Hold merge until the Rust-CLI installer fix is merged + deployed to cli.sfcompute.com.
• After merge, cut a release so the banner ships to legacy CLI users.

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
src/lib/upgrade.ts	36% smaller
src/checkVersion.ts	17% smaller
src/index.ts	16% smaller
install.sh	Unsupported file format
src/lib/migrate.ts	0% smaller

[indent]

PR Summary

Re-lands the sf migrate command + Rust CLI migration banner from PR #266 byte-for-byte after the temporary revert in PR #267. The original revert was triggered by an upstream bug in the cli.sfcompute.com install script (missing sf-old fallback), which the PR description claims has been fixed on sfcompute/sfcompute.

• Re-adds src/lib/migrate.ts with the sf migrate subcommand (downloads https://cli.sfcompute.com and pipes it into bash, with a Promise.race over close/error so spawn failures surface cleanly) and showMigrateBanner().
• Re-refactors checkVersion() to return Promise<boolean> so src/index.ts can suppress the cyan migrate banner whenever the yellow upgrade banner / auto-upgrade message has already run.
• Re-gates the migrate banner on !--json, subcommand ∉ {migrate, upgrade}, and a new SF_CLI_DISABLE_MIGRATE_BANNER opt-out; disables auto-upgrade when argv[2] === "migrate" to avoid the install scripts racing each other over ~/.local/bin/sf.
• Re-teaches install.sh to honor SF_CLI_TARGET_DIR / SF_CLI_BINARY_NAME overrides (and skip the PATH onboarding when they're set), and re-teaches src/lib/upgrade.ts to forward dirname/basename(process.execPath) so sf upgrade writes back to the binary's actual path instead of always clobbering ~/.local/bin/sf.

Issues

2 potential issues found:

• The upstream sf-old fallback bug that triggered the revert: "feat: [PR-1797] add sf migrate command and Rust CLI migration banner (#266)" #267 revert is still live at https://cli.sfcompute.com — check_existing_sf early-returns when the existing sf is at $INSTALL_DIR/$BINARY_NAME, then main() mvs the new binary over it. That's the default-on-default case (legacy ~/.local/bin/sf + new-CLI non-root INSTALL_DIR=~/.local/bin), so merging this re-land now reproduces the exact data-loss the revert addressed. Verify the Rust installer fix has actually deployed before merging (curl -fsSL https://cli.sfcompute.com | sed -n '112,135p' should no longer early-return when the paths match). → Autofix
• sf upgrade will now fail with EACCES for users whose binary lives in a privileged path (e.g. /usr/local/bin/sf): forwarding SF_CLI_TARGET_DIR=dirname(process.execPath) makes install.sh mkdir -p and mv into that exact directory with no sudo fallback. Previously the upgrade succeeded but silently dropped a stale duplicate at ~/.local/bin/sf; now it dies outright. The trade-off is explicitly chosen in the comment at upgrade.ts:74-77, but worth confirming you're okay with the regressed UX for that subset of users. → Autofix

CI Checks

All CI checks passed on commit bc4d835.

---

[capy-ai]

Capy auto-review is paused for this organization because the monthly auto-review limit has been reached. Increase the limit or turn it off in billing settings to resume automatic reviews.

[indent]

Latent UX regression for non-default install paths: when process.execPath is e.g. /usr/local/bin/sf, install.sh will now mkdir -p /usr/local/bin and mv "${TMPDIR}/dist/sf-$target" /usr/local/bin/sf (lines 50 and 129 of install.sh) without sudo. Both calls EACCES for non-root users, so the upgrade fails after fetching/extracting — a worse UX than the previous behavior of silently dropping a duplicate at ~/.local/bin/sf. The comment above explicitly chose this trade-off, so this is a callout, not necessarily a blocker — but if a user reports sf upgrade suddenly broken after this lands, this is the first place to look.

[indent]

Confirmed via curl -fsSL https://cli.sfcompute.com | sed -n '112,132p' that the live installer still has the buggy early-return in check_existing_sf, so this is currently a merge-block — landing it now would re-introduce the exact data-loss the revert was for. Once the installer fix ships and the same curl … sed snippet no longer short-circuits when paths match, this is safe to merge.

The sf upgrade EACCES regression for privileged install paths is unchanged from the original PR (no code delta vs #266) and remains the explicit trade-off documented at src/lib/upgrade.ts:74-77.

Generated by Indent - session link