fix(cli): update core app template

[cngonzalez]

Description

This updates the core app template to use the proper components for wrapping a core app. This is iterative, and likely not the final state of what this template looks like.

What to review

Does this seem all right as an initial intro to core apps for internal parties?

Testing

I'm running into issues with cutting a canary -- I ran into some kind of cache issue where any canary I released was seen as "already published". I can try again on Monday.

Notes for release

None, internal.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 21, 2025 9:45pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 21, 2025 9:45pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 21, 2025 9:45pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Feb 21, 2025 9:45pm
test-next-studio	⬜️ Ignored (Inspect)			Feb 21, 2025 9:45pm

[github-actions]

No changes to documentation

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	54993 / 127874
🔵	Statements	43%	54993 / 127874
🔵	Functions	48.12%	2797 / 5812
🔵	Branches	79.5%	10647 / 13392

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/@sanity/cli/templates/core-app/src/App.tsx	0%	100%	100%	0%	2-27
packages/@sanity/cli/templates/core-app/src/ExampleComponent.tsx	0%	0%	0%	0%	1-11

Generated in workflow #30835 for commit 705f12d by the Vitest Coverage Report Action

[github-actions]

⚡️ Editor Performance Report

Updated Fri, 21 Feb 2025 21:50:14 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
recipe (name)	50.0 efps (20ms)	43.5 efps (23ms)	+3ms (+15.0%)	✅
recipe (description)	55.6 efps (18ms)	50.0 efps (20ms)	+2ms (+11.1%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	+0ms (-/-%)	✅
synthetic (title)	18.7 efps (54ms)	19.4 efps (52ms)	-2ms (-3.7%)	✅
synthetic (string inside object)	20.4 efps (49ms)	20.0 efps (50ms)	+1ms (+2.0%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
recipe (name)	20ms	21ms	26ms	40ms	0ms	7.4s
recipe (description)	18ms	19ms	21ms	40ms	0ms	4.5s
recipe (instructions)	5ms	7ms	8ms	18ms	0ms	3.1s
synthetic (title)	54ms	56ms	67ms	294ms	1004ms	13.1s
synthetic (string inside object)	49ms	52ms	61ms	230ms	885ms	8.6s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
recipe (name)	23ms	24ms	27ms	45ms	6ms	7.5s
recipe (description)	20ms	21ms	22ms	64ms	0ms	5.0s
recipe (instructions)	5ms	7ms	8ms	17ms	0ms	3.1s
synthetic (title)	52ms	56ms	60ms	195ms	843ms	12.3s
synthetic (string inside object)	50ms	55ms	60ms	468ms	1060ms	8.5s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[github-actions]

Component Testing Report Updated Feb 21, 2025 9:54 PM (UTC)

❌ Failed Tests (4) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 26s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	14s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	❌ Failed (Inspect)	2m 41s	3	0	3
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	1m 0s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	30s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	17s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 17s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 50s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	❌ Failed (Inspect)	3m 0s	20	0	1
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	15s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	2m 2s	21	0	0
formBuilder/tree-editing/TreeEditing.spec.tsx	✅ Passed (Inspect)	0s	0	3	0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx	✅ Passed (Inspect)	0s	0	3	0