Add update-available notifier for the standalone (curl-installed) Studio CLI by bcotrim · Pull Request #3899 · Automattic/studio

bcotrim · 2026-06-19T10:56:59Z

Related issues

Related to STU-1772
Requires the wpcom studio-app/updates endpoint extension (224187-ghe-Automattic/wpcom) — merged and live in production. The curl installers (install.sh / install.ps1) are now served from public-api too, so the banner points at stable public-api.wordpress.com URLs rather than the wp.build short link.

How AI was used in this PR

Claude Code researched the Apps CDN / update-endpoint internals, designed the approach (reuse the desktop app's studio-app/updates endpoint rather than querying the internal CDN post type), implemented the client + tests, and validated the full request/response contract live (a wpcom sandbox during development, then production). It also caught and fixed a shell bug found during live end-to-end testing: the channel-pinned install command set STUDIO_CLI_VERSION= on the curl side of the pipe, so the piped bash ran the installer without it and 404'd — the env var now sits on the bash side. I reviewed all the code myself.

Proposed Changes

npm-installed CLIs already show an "update available" banner; standalone (curl-installed) CLIs got nothing. This gives curl installs the same nudge: when a newer version exists on the user's channel, the CLI prints a banner pointing them to re-run the installer.
It's channel-aware — production, beta, and nightly users are each checked against their own channel — by reusing the desktop app's existing update endpoint, so the server does the channel logic and version comparison. No coupling to internal CDN data models. The suggested update command is channel-pinned (STUDIO_CLI_VERSION=nightly|beta) so users stay on their channel.
It's quiet and non-intrusive: cached 24h, fast 3s non-blocking timeout, fails safe (no banner when offline or the endpoint is unavailable), and suppressed in IPC mode, with --json, and for the desktop-embedded CLI.

Testing Instructions

Automated: npm test -- apps/cli/lib/tests/update-notifier.test.ts (18 tests: banner variants, channel-pinned install commands, install-kind detection, 200/204/error handling, suppression matrix).

End-to-end — build a hardcoded dev bundle, see the banner, and update from it. Published nightlies don't include this notifier yet, so build a local bundle to exercise it. Run from the repo root:

Stamp the CLI to an old dev version so the endpoint reports an update — set "version": "1.12.0-dev1" in apps/cli/package.json.
Build the standalone bundle for your platform/arch: npm run cli:bundle -- darwin arm64. (cli:package prunes apps/cli/node_modules; run npm install afterward to restore it.)
Install it into ~/.studio from the local bundle (this repoints studio → ~/.studio/bin/studio and replaces any existing standalone install):
```
curl -fsSL https://public-api.wordpress.com/wpcom/v2/studio-app/install.sh | STUDIO_CLI_URL="$(pwd)/standalone-bundles" bash
```
Run any command — studio --version. Expect an update banner:
Update available: 1.12.0-dev1 → <latest nightly>, with Run curl -fsSL https://public-api.wordpress.com/wpcom/v2/studio-app/install.sh | STUDIO_CLI_VERSION=nightly bash to update.
Run that exact command to update → re-run studio --version: it's now the latest nightly and the banner is gone (you're current).
Negative checks: with --json, or as the desktop-embedded CLI → no banner.

Cleanup: revert apps/cli/package.json, npm install, rm -rf standalone-bundles, and (to restore your desktop app's studio) ln -sf "/Applications/Studio.app/Contents/Resources/bin/studio-cli.sh" ~/.local/bin/studio.

Pre-merge Checklist

Have you checked for TypeScript, React or other console errors? — typecheck clean for changed files, eslint clean, 18/18 tests pass.

fredrikekelund

I was originally envisioning an auto-updater for the standalone CLI. The difference between this packaging approach and npm is that with npm, we have explicitly handed over packaging responsibility to a package manager. In this case, we own packaging and there's no good reason to avoid auto-updating other than the effort it takes to implement.

Still, I think it's an OK tradeoff that we ship this implementation to begin with, but only if we also track bump stats for the number of users that run the standalone CLI. This can help us determine if we should revisit this in the future and implement an auto-updater for the standalone CLI.

fredrikekelund · 2026-06-23T07:56:51Z

+export function isStandaloneInstall(): boolean {
+	const home = process.env.STUDIO_CLI_HOME || path.join( os.homedir(), '.studio' );
+	return isPathInside( process.execPath, home );
+}


Did you consider adding a vite.config.standalone.ts file for the CLI that builds the CLI with a global variable, like __IS_PACKAGED_FOR_STANDALONE__?

Plenty of Vite configs, yes, but the explicitness of that approach is quite appealing, IMO.

I did look at this. The catch is create-standalone-bundle.ts reuses the same apps/cli/dist/cli the desktop app ships, so a __IS_PACKAGED_FOR_STANDALONE__ at build time would also be true for the embedded CLI unless we add a second, standalone-only build (separate dist + divergent bits). Runtime path detection avoids that and keeps app + standalone identical, which is why I went that way.

The catch is create-standalone-bundle.ts reuses the same apps/cli/dist/cli the desktop app ships

Does it really? I thought the cli:bundle script triggered a second npm run cli:package run (which in turn runs both install:bundle and build:prod for the CLI)..?

You are right. Added the suggested variable

fredrikekelund · 2026-06-23T07:59:46Z

 	try {
 		const content = fs.readFileSync( getCliConfigPath(), 'utf8' );
 		const data = JSON.parse( content );
-		return updateCheckSchema.parse( data?.updateCheck );
+		return updateCheckSchema.parse( data?.[ field ] );
 	} catch {
 		// File doesn't exist, field missing, or invalid
 	}
 	return null;


Why are we not using readCliConfig() here?

fredrikekelund · 2026-06-23T08:01:51Z

+	}
+
+	const prefix = alias ? `STUDIO_CLI_VERSION=${ alias } ` : '';
+	return `${ prefix }curl -fsSL https://wp.build/install.sh | bash`;


Suggested change

return `${ prefix }curl -fsSL https://wp.build/install.sh | bash`;

return `${ prefix }curl -fsSL https://wordpress.studio/install.sh | bash`;

Just relaying our discussion elsewhere. We're probably looking at this URL for the install command

For now I am using the public-api endpoint, to confirm the working behavior.
I propose updating the URL in a follow-up, once we have it set up

fredrikekelund · 2026-06-23T08:02:58Z

+
+	if ( platform === 'win32' ) {
+		const prefix = alias ? `$env:STUDIO_CLI_VERSION='${ alias }'; ` : '';
+		return `${ prefix }irm https://wp.build/install.ps1 | iex`;


Just noting that we need to double-check if irm follows redirects. If not, then I believe curl is available by default on Windows installations these days.

I think it does, but let's check back after updating the URL

fredrikekelund · 2026-06-23T08:03:52Z

+export function formatUpdateBanner(
+	currentVersion: string,
+	latestVersion: string,
+	updateCommand: string = NPM_UPDATE_COMMAND


Suggested change

updateCommand: string = NPM_UPDATE_COMMAND

updateCommand: string

Let's not default here. If the function has two modes, then the caller should be explicit about which to use

…ide of the pipe

…mand, readCliConfig

wpmobilebot · 2026-06-24T17:57:19Z

📊 Performance Test Results

Comparing d178196 vs trunk

app-size

Metric	trunk	`d178196`	Diff	Change
App Size (Mac)	1311.91 MB	1311.91 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	`d178196`	Diff	Change
load	1040 ms	1052 ms	+12 ms	⚪ 0.0%

site-startup

Metric	trunk	`d178196`	Diff	Change
siteCreation	6511 ms	6477 ms	34 ms	⚪ 0.0%
siteStartup	6505 ms	6998 ms	+493 ms	🔴 7.6%

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

fredrikekelund

LGTM Looks solid! Left a small comment about the URL we print when there's an update, but we could also handle that in a followup. Up to you.

fredrikekelund · 2026-06-24T19:51:40Z

+	// `VAR=x` scopes to curl only, so the piped bash runs install.sh without it and
+	// falls back to `latest`. `curl … | VAR=x bash` is what actually pins the channel.
+	const prefix = alias ? `STUDIO_CLI_VERSION=${ alias } ` : '';
+	return `curl -fsSL ${ STUDIO_API_BASE }/install.sh | ${ prefix }bash`;


Eventually, this should be https://wordpress.studio/install.sh. Would you rather do that in this PR or in a followup, @bcotrim?

fredrikekelund · 2026-06-24T19:53:34Z

+
+	if ( platform === 'win32' ) {
+		const prefix = alias ? `$env:STUDIO_CLI_VERSION='${ alias }'; ` : '';
+		return `${ prefix }irm ${ STUDIO_API_BASE }/install.ps1 | iex`;


Same thing here. This should be https://wordpress.studio/install.ps1 eventually

…com:Automattic/studio into stu-1772-add-update-workflow-curl-installer

…dio CLI (#3899) ## Related issues - Related to [STU-1772](https://linear.app/a8c/issue/STU-1772) - Requires the wpcom `studio-app/updates` endpoint extension (224187-ghe-Automattic/wpcom) — **merged and live in production**. The curl installers (`install.sh` / `install.ps1`) are now served from public-api too, so the banner points at stable `public-api.wordpress.com` URLs rather than the `wp.build` short link. ## How AI was used in this PR Claude Code researched the Apps CDN / update-endpoint internals, designed the approach (reuse the desktop app's `studio-app/updates` endpoint rather than querying the internal CDN post type), implemented the client + tests, and validated the full request/response contract live (a wpcom sandbox during development, then production). It also caught and fixed a shell bug found during live end-to-end testing: the channel-pinned install command set `STUDIO_CLI_VERSION=` on the `curl` side of the pipe, so the piped `bash` ran the installer without it and 404'd — the env var now sits on the `bash` side. I reviewed all the code myself. ## Proposed Changes - npm-installed CLIs already show an "update available" banner; standalone (curl-installed) CLIs got nothing. This gives curl installs the same nudge: when a newer version exists on the user's channel, the CLI prints a banner pointing them to re-run the installer. - It's channel-aware — production, beta, and nightly users are each checked against their own channel — by reusing the desktop app's existing update endpoint, so the server does the channel logic and version comparison. No coupling to internal CDN data models. The suggested update command is channel-pinned (`STUDIO_CLI_VERSION=nightly|beta`) so users stay on their channel. - It's quiet and non-intrusive: cached 24h, fast 3s non-blocking timeout, fails safe (no banner when offline or the endpoint is unavailable), and suppressed in IPC mode, with `--json`, and for the desktop-embedded CLI. ## Testing Instructions **Automated:** `npm test -- apps/cli/lib/tests/update-notifier.test.ts` (18 tests: banner variants, channel-pinned install commands, install-kind detection, 200/204/error handling, suppression matrix). **End-to-end** — build a hardcoded dev bundle, see the banner, and update from it. Published nightlies don't include this notifier yet, so build a local bundle to exercise it. Run from the repo root: 1. Stamp the CLI to an old dev version so the endpoint reports an update — set `"version": "1.12.0-dev1"` in `apps/cli/package.json`. 2. Build the standalone bundle for your platform/arch: `npm run cli:bundle -- darwin arm64`. (`cli:package` prunes `apps/cli/node_modules`; run `npm install` afterward to restore it.) 3. Install it into `~/.studio` from the local bundle (this repoints `studio` → `~/.studio/bin/studio` and replaces any existing standalone install): ``` curl -fsSL https://public-api.wordpress.com/wpcom/v2/studio-app/install.sh | STUDIO_CLI_URL="$(pwd)/standalone-bundles" bash ``` 4. Run any command — `studio --version`. Expect an **update banner**: `Update available: 1.12.0-dev1 → <latest nightly>`, with `Run curl -fsSL https://public-api.wordpress.com/wpcom/v2/studio-app/install.sh | STUDIO_CLI_VERSION=nightly bash to update`. 5. Run that exact command to update → re-run `studio --version`: it's now the latest nightly and the banner is gone (you're current). 6. Negative checks: with `--json`, or as the desktop-embedded CLI → no banner. Cleanup: revert `apps/cli/package.json`, `npm install`, `rm -rf standalone-bundles`, and (to restore your desktop app's `studio`) `ln -sf "/Applications/Studio.app/Contents/Resources/bin/studio-cli.sh" ~/.local/bin/studio`. ## Pre-merge Checklist - [x] Have you checked for TypeScript, React or other console errors? — typecheck clean for changed files, eslint clean, 18/18 tests pass.

Add update notifier for standalone (curl-installed) Studio CLI

ebaf9c2

github-actions Bot assigned bcotrim Jun 19, 2026

Make standalone CLI update banner channel- and OS-aware

5ce409d

fredrikekelund reviewed Jun 23, 2026

View reviewed changes

bcotrim and others added 7 commits June 23, 2026 12:10

Point standalone CLI update banner at the public-api installer URL

5d1d131

Remove install scripts from repo (now served from wpcom)

f1b8d76

Fix standalone update command: place STUDIO_CLI_VERSION on the bash s…

02fd172

…ide of the pipe

Merge branch 'trunk' into stu-1772-add-update-workflow-curl-installer

08d0f14

Address review feedback: standalone launch stats, explicit banner com…

dc4c285

…mand, readCliConfig

Detect standalone CLI via a build-time flag instead of runtime path

6e168b0

Fix standalone banner test failing on the Windows CI matrix

5fefe75

bcotrim marked this pull request as ready for review June 24, 2026 10:34

bcotrim requested a review from fredrikekelund June 24, 2026 10:34

Merge branch 'trunk' into stu-1772-add-update-workflow-curl-installer

ba2d23c

fredrikekelund approved these changes Jun 24, 2026

View reviewed changes

bcotrim added 2 commits June 25, 2026 14:13

Point the standalone update banner at the wordpress.studio install URL

d6ea4f7

Merge branch 'stu-1772-add-update-workflow-curl-installer' of github.…

d178196

…com:Automattic/studio into stu-1772-add-update-workflow-curl-installer

bcotrim merged commit 17451f7 into trunk Jun 26, 2026
11 checks passed

bcotrim deleted the stu-1772-add-update-workflow-curl-installer branch June 26, 2026 08:50

	return `${ prefix }curl -fsSL https://wp.build/install.sh \| bash`;
	return `${ prefix }curl -fsSL https://wordpress.studio/install.sh \| bash`;

	updateCommand: string = NPM_UPDATE_COMMAND
	updateCommand: string

Uh oh!

Conversation

bcotrim commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related issues

How AI was used in this PR

Proposed Changes

Testing Instructions

Pre-merge Checklist

Uh oh!

fredrikekelund left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bcotrim Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wpmobilebot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📊 Performance Test Results

app-size

site-editor

site-startup

Uh oh!

fredrikekelund left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bcotrim commented Jun 19, 2026 •

edited

Loading

bcotrim Jun 24, 2026 •

edited

Loading

wpmobilebot commented Jun 24, 2026 •

edited

Loading