fix: add missing appId warning to app build

[bjoerge]

Description

Two issues fixed:

1. buildApp was missing the warnAboutMissingAppId call that buildStudio had when auto-updates are enabled but no appId is configured.

2. Both buildStudio and buildApp now skip the warning when called from
   deploy, since deploy handles appId itself (prompts the user to select/create an app and tells them to add it to config).

Added calledFromDeploy option to BuildOptions, set by deployStudio and deployApp so it can be ignored when build is invoked from deploy.

What to review

Makes sense?

Testing

Tests included

[linear]

SDK-970 `warnAboutMissingAppId` fixes

9. warnAboutMissingAppId Missing from App Build

Original app build warns about missing appId when auto-updates enabled. New CLI omits this entirely.

10. warnAboutMissingAppId Always Shows in Studio Build

Original suppresses warning when called from deploy (since deploy has its own appId handling). New CLI always shows it.

[claude]

Claude finished @bjoerge's task in 2m 24s —— View job

---

Review

• Read changed files
• Analyze implementation
• Post review feedback

---

The implementation is correct and the approach makes sense. One minor observation:

buildApp.ts warning placement (line 66 vs 73)

warnAboutMissingAppId is called at line 73, but getAutoUpdatesImportMap at line 66 already uses the (potentially undefined) appId. The warning would be marginally clearer if shown before the import map is configured — but this is cosmetic and has no functional impact since the build proceeds correctly regardless.

Test consistency note (buildStudio.appIdWarning.test.ts, line 104)

The autoUpdatesEnabled: true option passed to buildStudio in the tests is dead code — buildStudio ignores options.autoUpdatesEnabled and calls shouldAutoUpdate() internally (unlike buildApp which uses the option directly). This is a pre-existing design inconsistency in BuildOptions, not introduced by this PR. The tests work correctly via the shouldAutoUpdate mock, and the comment at line 135–136 explains it. Worth documenting in BuildOptions (e.g. a JSDoc noting the field is only honored by buildApp, not buildStudio) to avoid future confusion — but not blocking.

Everything else looks good: the calledFromDeploy guard is correctly applied in both buildApp and buildStudio, the flag is correctly set in deployApp and deployStudio, the omission of projectId from the buildApp warning call is intentional (apps use organizationId, not projectId), and the test coverage covers all four relevant cases.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	77.42%	7290 / 9415
🔵	Statements	76.99%	7511 / 9755
🔵	Functions	73.98%	1223 / 1653
🔵	Branches	64.35%	3393 / 5272

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/@sanity/cli/src/actions/build/buildApp.ts	94.93%	94.33%	100%	94.8%	45, 54-55, 105
packages/@sanity/cli/src/actions/build/buildStudio.ts	97.5%	96.07%	100%	97.46%	59, 126
packages/@sanity/cli/src/actions/deploy/deployApp.ts	84.21%	81.25%	100%	84.21%	38, 43, 88, 99-101, 145-146, 152
packages/@sanity/cli/src/actions/deploy/deployStudio.ts	94%	100%	100%	94%	32, 37, 130

Generated in workflow #2519 for commit 07ad2f8 by the Vitest Coverage Report Action