Repository navigation
feat: ask about updates at startup, in the app and the terminal - #305
Merged
Merged
Conversation
The desktop app has always checked at launch, but the only sign of an update was a titlebar arrow, and only once the download had finished. A fork-only UpdatePrompt now opens a dialog the first time a check reports an available or ready update: Install and restart, or Not yet. The terminal app had the same feature and none of the effect. Its check ran on a one-second timer and announced itself with installation.update-available, which the TUI has a confirm dialog for — but Rpc.emit is a bare postMessage and the TUI registers its handlers while it renders, a few hundred milliseconds after the check resolved. The event was delivered into an empty handler set every launch. The check now starts from a new TuiInput.onReady, called once those handlers exist. While there: only an explicit `autoupdate: true` installs a patch release by itself. The default asks, like every other release type. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Both apps already checked for updates at launch. Neither told the user.
Desktop
updater.start()has always run a check at launch, but on the new layout the only thing that surfaced it was a small arrow in the titlebar — and only once the download had finished. (The legacy layout'sUpdateAvailableToastis unreachable:newLayoutDesignsis alwaystrue.)New fork-only
packages/app/src/components/dialog-update.tsx:<UpdatePrompt />renders nothing, watches the updater, and opens the dialog the first time the state becomesavailableorready— once per app run, not once per mount.<DialogUpdate />names the version and offers Not yet plus the state-appropriate action, reusinguseUpdaterAction(): Download when automatic downloading is off, Install and restart once it is downloaded, a loader while either runs. Existingtoast.update.*/settings.updates.action.*keys, so no new strings.Mounted from
pages/layout-new.tsx(one import, one element).Terminal
The TUI has had a confirm dialog for
installation.update-availableall along, and it could never appear.cmd/tui.tsfiredcheckUpgradeon a one-second timer; the TUI registers itsevent.on(...)handlers while it renders, a few hundred milliseconds later; andRpc.emitis a barepostMessage— an event with no subscribers is dropped, not queued. Traced end to end: worker forwards the event at T, the App's handlers register at T+800ms, event gone.Fix:
TuiInputgainsonReady?: () => void, called once the App has registered its handlers;cmd/tui.tspassescheckUpgradeasonReadyand drops the timer. Ordering rather than a longer timeout, so it cannot race.Also in
cli/upgrade.ts: a newer version now asks unless the user opted into automatic patch installs.const silent = config.autoupdate === true && getReleaseType(...) === "patch".autoupdate: falseandCODEV_DISABLE_AUTOUPDATEstill skip the check;"notify"andCODEV_ALWAYS_NOTIFY_UPDATEare unchanged.Test plan
bun run devwith the updater backend temporarily stubbed to report version 9.9.9, and confirmed the dialog over the renderer via CDP — "Update available / A new version of CoDev (9.9.9) is now available to install." with Not yet and Install and restart. Stub reverted.Installation.latest()temporarily stubbed, and the dialog appears at startup — "Update Available / A new release v9.9.9 is available. Would you like to update now?" with Skip / Confirm. Before the fix the same stub produced nothing; traces showed the event forwarded by the worker and delivered into an empty handler set. Stub reverted.bun typecheckinpackages/app,packages/tui,packages/opencode.bun run test:unitinpackages/app(695 pass);bun testinpackages/tui(266 pass);bun test test/cliinpackages/opencode(375 pass).DIVERGENCES.md gains two rows (the three upstream CLI/TUI files, and the
layout-new.tsxmount); CHANGELOG.md gains two Unreleased entries under Updates.🤖 Generated with Claude Code