Upgrade Sanity Studio v5 → v6

[thecodedrift]

Summary

Upgrade the embedded Sanity Studio from v5 (sanity@5.31.1) to v6 (sanity@6.4.0).

This is a maintenance upgrade, not a security fix. See "Does not fix the uuid advisory" below — that assumption turned out to be false, and the two issues should be handled separately.

Scope

The Studio is embedded in-app (not a separate workspace):

• sanity.config.ts — defineConfig, plugins [structureTool(), codeInput(), visionTool()]
• app/components/studio-embed.client.tsx — renders <Studio config={config} />, client-only
• app/routes/studio.tsx + app/routes.ts — mounts at /_/studio/*
• app/sanity/schemas/{post,til,tag}.ts — defineType / defineField / defineArrayMember

Dependency changes

Package	Now	Target	Notes
sanity	^5.31.1	^6.4.0	the upgrade
@sanity/vision	^5.31.1	^6.4.0	peer requires sanity@^6
@sanity/code-input	^7.2.6	unchanged	already declares sanity: "^5 || ^6"
@sanity/client	^7.23.0	unchanged	versioned independently of Studio
@sanity/image-url	^2.1.1	unchanged	versioned independently of Studio

Peer requirements — all already satisfied

sanity@6.4.0 requires Node >=22.12 (we pin 24 via .nvmrc), react/react-dom ^19.2.2 (we have ^19.2.7), styled-components ^6.1.15 (we have ^6.4.3). No transitive upgrades needed.

Breaking changes, assessed against this repo

v6 breaking change	Applies here?
Min Node bumped to 22.12	No — already on 24
auth.providers no longer appends; mode removed	No — no auth config
Default search strategy groqLegacy → groq2024	Cosmetic — changes the Studio's own search UI ordering/counts. Our GROQ in app/sanity/queries.ts runs through @sanity/client, unaffected
reactStrictMode defaults to true	No — set in sanity.cli, which we don't have; applies to sanity dev, which we never run
Studio build moves to Vite 8	No — applies to sanity build. Our build is react-router build on our own Vite 7

No codemod is published; the documented upgrade is a version bump and redeploy.

The actual risk

The one thing not covered by the official guidance: we do not consume the Studio the way the upgrade notes assume. We bundle it into our own Vite 7 build via vite.config.ts:

noExternal: [/^sanity($|\/)/, /^@sanity\//, "styled-components"]

So sanity@6's shipped ESM gets processed by our Vite 7, not the Vite 8 it was built against. That's the most plausible place this breaks, and it won't surface in typecheck — only in a real build and a real page load at /_/studio.

Does not fix the uuid advisory

Dry-resolving sanity@6 in isolation (pnpm install --lockfile-only in a scratch project) shows the moderate advisories persist and one is added:

{"high":0,"moderate":5,"critical":0}
  [moderate] uuid      via sanity > @sanity/cli > typeid-js > uuid@10.0.0
  [moderate] js-yaml   via sanity > @sanity/cli > @vercel/frameworks > js-yaml
  [moderate] smol-toml via sanity > @sanity/cli > @vercel/frameworks > smol-toml   (new in v6)

@sanity/cli still pulls typeid-js → uuid@10 and @vercel/frameworks → js-yaml@3.13.1 (hard-pinned). All of it is dev tooling — verified absent from the built Worker bundle. Clearing uuid needs a pnpm.overrides entry, independent of this upgrade.

Tasks

• pnpm add sanity@^6 @sanity/vision@^6
• pnpm typecheck && pnpm lint && pnpm build
• Load /_/studio and confirm it mounts (this is the Vite 7 × Studio-v6 bundling risk)
• In the Studio: create/edit a post and a TIL, exercise a type: "code" field (@sanity/code-input), open Vision
• Confirm public routes still render — /blog, a post, /til, an entry, /sitemap.xml
• Confirm signed OG cards still generate (valid sig → PNG, forged → 302)
• Re-run pnpm audit; expect smol-toml to appear, and decide whether to override it alongside js-yaml

Rollback

Single commit; revert restores sanity@5 and @sanity/vision@5. Nothing in the content model, dataset, or GROQ changes, so there is no data migration and no forward-incompatible state.

References

• Sanity Studio v6: A focused upgrade
• Upgrading Sanity Studio