feat: create runtime resources

[cngonzalez]

Description

The initial way of thinking about injecting resources, via a renderSanityApp, meant that any top-level parameters (like auth options, or any new parameters) would have to be lifted to sanity.cli.ts and coordinated with a CLI release. It also meant that there was a bit of friction between the SDK and CLI versions -- what if someone went to a new CLI but was on SDK v2? Or vice versa?

This PR simplifies things by assuming the shape of an SDK App is largely the same. We still get the benefits of having resources in an easily-serializable and readable form in sanity.cli.ts, but we can now import it from a file we generate and track. It also offers type safety for resourceName.

(This PR is an update on ideas brought forward in internal documents about maintaining a Vite plugin -- it was decided to go simpler, with less magic).

This PR purposely does not update the existing app templates to read from this directory yet -- that can come in a separate PR.

What to review

I'm most curious about the resources file -- its placement and name. Does it seem all right? Any issues?

Testing

Some tests were added.

Notes for release

Writes .sanity/resources.ts with type-safe resource declarations during app build and dev server start

[cngonzalez]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat: create runtime resources #961 👈 (View in Graphite)
• feat: add app resources to sanity.cli.ts #878 : 1 other dependent PR (#912 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

📦 Bundle Stats — @sanity/cli

Compared against stack/sdk-711-app-resources-base (5c73dc97)

@sanity/cli

Metric	Value	vs stack/sdk-711-app-resources-base (5c73dc9)
Internal (raw)	2.1 KB	-
Internal (gzip)	799 B	-
Bundled (raw)	10.95 MB	-
Bundled (gzip)	2.05 MB	-
Import time	836ms	+0ms, +0.0%

bin:sanity

Metric	Value	vs stack/sdk-711-app-resources-base (5c73dc9)
Internal (raw)	975 B	-
Internal (gzip)	460 B	-
Bundled (raw)	9.84 MB	-
Bundled (gzip)	1.77 MB	-
Import time	944ms	+5ms, +0.5%

🗺️ View treemap · Artifacts

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

📦 Bundle Stats — @sanity/cli-core

Compared against stack/sdk-711-app-resources-base (5c73dc97)

Metric	Value	vs stack/sdk-711-app-resources-base (5c73dc9)
Internal (raw)	93.2 KB	-
Internal (gzip)	21.9 KB	-
Bundled (raw)	21.62 MB	-
Bundled (gzip)	3.42 MB	-
Import time	796ms	+6ms, +0.8%

🗺️ View treemap · Artifacts

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

📦 Bundle Stats — create-sanity

Compared against stack/sdk-711-app-resources-base (5c73dc97)

Metric	Value	vs stack/sdk-711-app-resources-base (5c73dc9)
Internal (raw)	976 B	-
Internal (gzip)	507 B	-
Bundled (raw)	50.7 KB	-
Bundled (gzip)	12.6 KB	-
Import time	❌ ChildProcess denied: node	-

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

[claude]

Claude finished @cngonzalez's task in 2m 31s —— View job

---

Review

• Read CLAUDE.md and gather context
• Analyze PR diff
• Review changed files
• Post review findings

---

1. Changeset summary is too vague

.changeset/pr-961.md has summary "create runtime resources" — this doesn't describe what changes for the developer. Per conventions, one sentence describing the user-facing effect, e.g.:

Writes .sanity/resources.ts with type-safe resource declarations during app build and dev server start

2. .sanity/resources.ts is always written as .ts regardless of useTypeScript flag

bootstrapLocalTemplate.ts:157 always writes .sanity/resources.ts, but the file contains TypeScript-only syntax (import type, satisfies, declare module augmentation). If app templates support a JS-mode init (useTypeScript: false), this will produce a TypeScript file in a project with no tsconfig.

If app templates are TypeScript-only, this is fine — but it's worth an explicit check or comment guarding this assumption. Fix this →

3. resources.ts is not re-generated when sanity.cli.ts changes during dev

writeSanityRuntime.ts:72–76 — the chokidar watcher only watches getPossibleDocumentComponentLocations(cwd) and calls renderAndWriteDocument() on changes. If a developer adds or changes a resource in sanity.cli.ts during a live dev session, resources.ts won't be updated until they restart the dev server. This is a subtle footgun that should at minimum be documented (e.g., a // note: changes to resources in sanity.cli.ts require a dev server restart comment near the watcher setup, or surfaced as a warning in the output).

4. Missing init-flow test coverage

There's a new integration test for the build and dev commands that verify .sanity/resources.ts is written correctly, but there's no corresponding test for the init path (bootstrapLocalTemplate.ts:144–157). The coverage report confirms bootstrapLocalTemplate.ts coverage dropped slightly (-0.1%). A test asserting that sanity init with an app template creates the correct .sanity/resources.ts file (with default projectId/dataset from variables) would close this gap.

---

On the file placement question (.sanity/resources.ts): The location looks reasonable — it's adjacent to .sanity/runtime/ which already exists, it's a stable committed file (not regenerated-only like the runtime dir), and the gitignore change from /.sanity to /.sanity/runtime cleanly separates ephemeral from tracked output. One consideration: existing app projects that already have /.sanity in their .gitignore would need a manual update to start tracking resources.ts. That's probably acceptable scope for a follow-up, but worth calling out in migration notes.

[github-actions]

Coverage Delta

File	Statements
packages/@sanity/cli-core/src/config/cli/schemas.ts	100.0% (±0%)
packages/@sanity/cli/src/actions/build/buildApp.ts	94.9% (±0%)
packages/@sanity/cli/src/actions/build/buildStaticFiles.ts	96.5% (±0%)
packages/@sanity/cli/src/actions/build/writeSanityRuntime.ts	96.9% (+ 1.6%)
packages/@sanity/cli/src/actions/dev/startAppDevServer.ts	87.5% (+ 0.5%)
packages/@sanity/cli/src/actions/init/bootstrapLocalTemplate.ts	90.2% (+ 0.5%)
packages/@sanity/cli/src/actions/init/createAppCliConfig.ts	100.0% (±0%)
packages/@sanity/cli/src/actions/init/createPackageManifest.ts	100.0% (±0%)
packages/@sanity/cli/src/commands/resources.ts	93.3% (new)
packages/@sanity/cli/src/server/devServer.ts	94.1% (±0%)

Comparing 10 changed files against main @ 2fd358fc52ed3e2c3b89e45796e4a6044e03cd4c

Overall Coverage

Metric	Coverage
Statements	84.0% (+ 0.0%)
Branches	73.8% (+ 0.1%)
Functions	83.9% (+ 0.0%)
Lines	84.4% (+ 0.0%)

[cngonzalez]

Looking for feedback on this as the filepath for this automatically generated file. It can live elsewhere, I wasn't quite sure.

This means that users will see an explicit /.sanity directory in their IDEs etc.

[cngonzalez]

Closing for now, since we're not going in this direction.