feat(cli): add non-studio app template

[cngonzalez]

Description

This PR adds a template for applications that are not Sanity Studios. Because we are still considering requirements and scope, this app is a very minimal Vite / React application, but this may be expanded in the future.

We would still like these applications to be behind the sanity CLI runtime, so we've made some tweaks to allow sanity dev, sanity build and so on to run a Vite app.

A TLDR of what's included in this PR:

1. Boilerplate / static files for a non-studio application:
   a. The Document / index.html file
   b. The sanity.cli.ts|js file
   c. The app.js entrypoint
2. An additional parameter to CLI config to configure a non-studio application, __experimental_coreAppConfiguration. Right now it only determines framework and an entry path.
3. Changes to the sanity init and template bootstrapping commands. If a non-studio application template is detected, it will not prompt for project-specific information or add studio-specific files and dependencies.
4. Various checks throughout server commands, mostly to ensure help text is accurate, and that the correct static files are being used.

What to review

This PR is not a complete vision. There will be fast follows to add the following:

1. Organization-specific information and deployment
2. Adding specific scripts to non-studio templates -- for example, dev should default to running in a framed application.
3. Ways to pass down additional parameters from configuration. We don't have the mechanisms right now to do things the Studio does, like pass down an application title, or whether to run in React Strict Mode.
4. Changes to eslint config generation so it's not studio-specific.

Beyond that, I'm interested in opinions on things like:

1. the cli config option as a flag
2. The location of various templates

Testing

I didn't see ways to easily add tests for this -- our command tests (like dev and build) do not seem to accept CLI configuration options. Probably the best way to test is to:

1. mkdir core-app
2. cd core-app
3. pnpx [email protected]+df28986158 init --template core-app
4. After creating the app, change the sanity entry in your package.json devDependencies to 3.72.2-canary.32+df28986158 and pnpm install
5. Play around with pnpm dev, pnpm build, pnpm start

OR you could the following:

1. Pull down this branch
2. cd ./packages/sanity
3. Copy the pwd of where you are for future use (for me, it is /Users/carolina/code/sanity/packages/sanity)
4. Run pnpm build and pnpm watch (if you'd like to make changes)
5. In another terminal window, run {pwd}/bin/sanity init --template core-app (so something like/Users/carolina/code/sanity/packages/sanity/bin/sanity init --template core-app)
6. Observe the initialization flow
7. pnpm link {your output from step #3} so something like pnpm link /Users/carolina/code/sanity/packages/sanity
8. Play around with pnpm dev, pnpm build and pnpm start

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 4, 2025 9:20pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 4, 2025 9:20pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 4, 2025 9:20pm

2 Skipped Deployments

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

[github-actions]

No changes to documentation

[github-actions]

⚡️ Editor Performance Report

Updated Tue, 04 Feb 2025 21:22:58 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	19.6 efps (51ms)	22.0 efps (46ms)	-6ms (-10.8%)	✅
article (body)	63.5 efps (16ms)	67.6 efps (15ms)	-1ms (-/-%)	✅
article (string inside object)	25.0 efps (40ms)	23.8 efps (42ms)	+2ms (+5.0%)	✅
article (string inside array)	21.3 efps (47ms)	20.4 efps (49ms)	+2ms (+4.3%)	✅
recipe (name)	41.7 efps (24ms)	47.6 efps (21ms)	-3ms (-12.5%)	✅
recipe (description)	47.6 efps (21ms)	52.6 efps (19ms)	-2ms (-9.5%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	-0ms (-/-%)	✅
synthetic (title)	17.2 efps (58ms)	18.0 efps (56ms)	-3ms (-4.3%)	✅
synthetic (string inside object)	17.9 efps (56ms)	17.9 efps (56ms)	+0ms (-/-%)	✅

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
article (title)	51ms	72ms	97ms	532ms	1176ms	11.7s
article (body)	16ms	19ms	36ms	182ms	286ms	5.8s
article (string inside object)	40ms	43ms	51ms	223ms	389ms	7.3s
article (string inside array)	47ms	49ms	53ms	319ms	632ms	7.9s
recipe (name)	24ms	26ms	28ms	46ms	0ms	7.8s
recipe (description)	21ms	23ms	26ms	38ms	1ms	5.1s
recipe (instructions)	5ms	7ms	7ms	20ms	0ms	3.0s
synthetic (title)	58ms	62ms	75ms	619ms	2067ms	14.4s
synthetic (string inside object)	56ms	58ms	63ms	808ms	2038ms	9.7s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	46ms	64ms	83ms	493ms	1028ms	11.5s
article (body)	15ms	17ms	21ms	165ms	329ms	5.6s
article (string inside object)	42ms	44ms	52ms	156ms	395ms	7.5s
article (string inside array)	49ms	51ms	59ms	184ms	398ms	7.5s
recipe (name)	21ms	22ms	23ms	49ms	0ms	7.5s
recipe (description)	19ms	20ms	22ms	45ms	0ms	4.6s
recipe (instructions)	5ms	6ms	7ms	24ms	0ms	3.1s
synthetic (title)	56ms	59ms	86ms	442ms	1970ms	16.8s
synthetic (string inside object)	56ms	59ms	68ms	472ms	1781ms	9.4s

📚 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 4, 2025 9:21 PM (UTC)

❌ Failed Tests (1) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 4s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	12s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	❌ Failed (Inspect)	1m 19s	5	0	1
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	51s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	15s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	27s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 7s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 30s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	2m 2s	21	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	13s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	1m 42s	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

[binoy14]

Tested it locally with the canary and everything looks good. Code looking good as well, thanks for the effort!

[binoy14]

Might be a good quality of life of improvement if it's different port from studio but if it's too much work than don't worry about it.

Suggested change

	--port <port> TCP port to start server on. [default: 3333]
	--port <port> TCP port to start server on. [default: 3334]

[jordanl17]

Yeh, I agree this would be a nice fast-follow improvement

[jordanl17]

High level the changes make sense to me

[jordanl17]

Yeh, I agree this would be a nice fast-follow improvement