Log CLI Tracks events in the terminal during npm start

[wojtekn]

Related issues

• Related to STU-2170

How AI was used in this PR

Claude Code investigated why CLI Tracks events were invisible in dev, proposed and implemented the fix, added tests, and updated the design doc. I reviewed the reasoning — in particular confirming the new NODE_ENV === 'development' condition is a strict subset of the shared core's dev/E2E no-op, so it cannot cause a real pixel to fire in any shipped or CI build.

Proposed Changes

When running Studio locally with npm start, the desktop Main process already logs a Would have recorded Tracks event: studio_app_launch { … } line for each event — useful when debugging analytics or reviewing a Tracks PR. CLI-emitted events (notably studio_site_start) printed nothing in a plain dev run, so there was no parity: you couldn't see a CLI event fire without a manual multi-env-var incantation.

This makes CLI Tracks events log the same Would have recorded… line automatically during npm start, matching the desktop behavior with no extra setup. The CLI wrapper now treats NODE_ENV === 'development' (inherited by the forked CLI child from the desktop) as an escape hatch, letting the call reach the shared core — which logs the line and no-ops the network in dev.

This is a debug-visibility change only. The shared core remains the single guardian that no real pixel fires in dev/E2E, and the new condition is a strict subset of that no-op condition, so it cannot leak analytics. The build-time __ENABLE_CLI_TELEMETRY__ gate still fully protects standalone dev CLI builds and all shipped/CI builds (verified nothing outside test files sets NODE_ENV=development). It also fixes a small asymmetry: the desktop already fell through to the shared core in dev while the CLI's stricter gate did not.

Testing Instructions

Automated:

• npm test -- apps/cli/lib/tests/tracks.test.ts — includes new cases for the dev pass-through and that opt-out still wins in dev.
• npm run typecheck

End-to-end (manual):

1. npm run cli:build
2. npm start
3. Start a site from the UI and watch the npm start terminal. You should see, alongside the existing studio_app_launch line:

[CLI - <siteId>] Would have recorded Tracks event: studio_site_start {
  platform: 'darwin', arch: 'arm64', app_version: '1.17.0',
  is_a11n: true, channel: 'studio-ui', ui_version: 'v1'
}

Confirmed working locally. No real network request is made (shared core no-ops in dev).

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing b99a24b vs trunk

app-size

Metric	trunk	b99a24b	Diff	Change
App Size (Mac)	1378.88 MB	1378.88 MB	0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	b99a24b	Diff	Change
load	1099 ms	1113 ms	+14 ms	⚪ 0.0%

site-startup

Metric	trunk	b99a24b	Diff	Change
siteCreation	6532 ms	6554 ms	+22 ms	⚪ 0.0%
siteStartup	2375 ms	2391 ms	+16 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

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

[sejas]

Works as expected. Thanks!
I run npm start and started a site from the UI:

I left a suggestion, but I don't have all the context.

[sejas]

Should we just set STUDIO_FORCE_CLI_TELEMETRY to true in vite.config.dev.ts?

studio/apps/cli/vite.config.dev.ts

Line 17 in b99a24b

__ENABLE_CLI_TELEMETRY__: false,

[wojtekn]

If we set it in vite.config.dev.ts, it would be included in the dev builds, which are used during E2E, but it wouldn't change anything when we run the app in dev mode locally.

• __ENABLE_CLI_TELEMETRY__ enables telemetry for all users on production build and npm release (but no for dev builds)
• STUDIO_FORCE_CLI_TELEMETRY allows testing telemetry for built dev builds
• NODE_ENV handles app running in dev mode.