⚠️ THIS IS A MAINTENANCE RELEASE OF A PREVIOUS MAJOR VERSION OF SANITY

We recommend updating to Sanity Studio v3 which provides exceptional flexibility and an unparalleled developer experience. The core packages for Sanity Studio v2 will only receive critical bug fixes until Dec 7th, 2023

Please head over to the documentation for Sanity Studio v3 to learn more.

You can find migration guides from Studio v2 here.

Installation and upgrading

Upgrade the v2 version of the Command Line Interface (CLI) with:

npm install --global @sanity/cli@v2

Upgrade Sanity Studio with:

sanity upgrade

🐛 Notable bugfixes

• Fixes an issue that could give false validation errors for complex documents

📓 Full changelog

Installation and upgrading

To initiate a new Studio without installing the CLI globally:

npx create-sanity@latest

To upgrade a v3 Studio:

npm install sanity@latest

🐛 Notable bugfixes

• Fixed a regression with release 3.1.0 where a custom style in the portable text input would not fallback to be rendered as the normal style when a rendering-component for that style was not defined.

📓 Full changelog

Installation and upgrading

To initiate a new Studio without installing the CLI globally:

npx create-sanity@latest

To upgrade a v3 Studio:

npm install sanity@latest

🐛 Notable bugfixes

• Fixes an issue where createAuthStore would incorrectly require a client factory to be passed
• Fixes an issue where lodash was not optimized in all released Sanity packages
• Fixes an issue where disabling direct uploads when using multiple asset sources would not work

📓 Full changelog

Installation and upgrading

To initiate a new Studio without installing the CLI globally:

npx create-sanity@latest

To upgrade a v3 Studio:

npm install sanity@latest

✨ Highlights

Improved customization and TypeScript support for the Portable Text Input and schemas

Improved support for custom rendering of the content in the Portable Text input via .components.block, component.inlineBlock and .components.annotation render callbacks for object-like schema types, references and type aliases.

While this has been possible previously by modifying the block schema locally, these customizations can now also be put directly on the various content types themselves, to be shared between different Portable Text inputs using them. For example you can now customize how an author reference would appear in various Portable Text contexts on the author schema itself.

Also text specific schema properties like decorators, styles and lists for the block type itself have slighly changed their configuration in order to better align with the rest of the studio. More info: Changes in block schema customization properties.

If you previously did customization of the editor using your own render callbacks or icons through the .blockEditor property in the block schema, you will get a deprecation warning, but they will still continue to work until further notice.

Please refer to the documentation for how to customize the block type and the Portable Text editor for v3 of the studio.

Besides this, the Portable Text input related code and schema types have been given a TypeScript update for better type safety and developer experience.

Studio appearance

The user menu now has options to select the appearance (color scheme) of the Studio. The selected appearance is stored in local storage and is reused on the next visit.

Logo component updates

The button in the navbar that wraps the custom logo component has no padding anymore. This update is made in order to give the custom logo component full control over how big the button in the navbar should be. Therefore, the custom logo component may need to be updated in order to achieve the previous look. Below is an example of how to recreate the same result as before:

import {defineConfig} from 'sanity'
import {Box} from '@sanity/ui'

function MyLogo() {
  return (
    <Box padding={3}> // <-- Wrap your custom logo with a `Box` with `padding={3}`
      <CustomLogo />
    </Box>
  )
}

export default defineConfig({
  // ... rest of config

  studio: {
    components: {
      logo: MyLogo,
    },
  },
})

🐛 Notable bugfixes

• This update fixes so that the component in the root config (ie in defineConfig) is the component that receives the result of the props passed on with renderDefault in previous custom components.
• Fixed an issue with custom sort orders

📓 Full changelog

⚠️ THIS IS A MAINTENANCE RELEASE OF A PREVIOUS MAJOR VERSION OF SANITY

We recommend updating to Sanity Studio v3 which provides exceptional flexibility and an unparalleled developer experience. The core packages for Sanity Studio v2 will only receive critical bug fixes until Dec 7th, 2023

Please head over to the documentation for Sanity Studio v3 to learn more. You can find migration guides from Studio v2 here.

Installation and upgrading

Upgrade the v2 version of the Command Line Interface (CLI) with:

npm install --global @sanity/cli@v2

Upgrade Sanity Studio with:

sanity upgrade

🐛 Notable bugfixes

• Improves inputmode detection for number input (#3867)
• Fixes an issue causing reference field filters not to update in some cases (#3901)

📓 Full changelog

Sanity Studio v3

This is the release of the stable, production-ready version the new major version (v3) of Sanity Studio. It deprecates Studio v2 and earlier versions. Studio v3 brings new features for content creators and developers, as well as a completely rewritten studio customization framework.

High-level improvements

• The Parts system is deprecated and replaced with a new studio customization framework
• Custom webpack tooling is replaced with Vite
• Sanity Studio now ships as a single npm dependency ([sanity](https://www.npmjs.com/package/sanity)) with JavaScript-based configuration (sanity.config.js|ts / sanity.cli.js|ts)
• The Studio module also has full ECMAScript Modules (ESM) support and CommonJS fallback and can be run in all modern browsers without bundling and embedded in any web project
• Full TypeScript coverage with annotated APIs (@internal, @beta, @public), new helper functions (defineType,defineField), and emerging inline documentation with TS Doc
• Better abstractions for wrapping and composing Studio and Form Components with renderDefault(props) and other convenience functions.
• New Plugins API with plugin development tooling (plugin-kit) that makes it easier to build, maintain, and publish plugins on npm
• New Studio v3 templates that let you get up and running with best practices

Learn more about Studio v3

• New documentation
• Migration guides

Installation and upgrading

To globally install/upgrade the v3 Sanity CLI:

npm install --global sanity@dev-preview

To validate you're on @3.0.0-rc.3:

$ sanity --version
> sanity version 3.0.0-rc.3

The new CLI should work with existing v2 studios, but you won't be able to initialize new v2 studios with it.

To initiate a new Studio without installing the CLI globally:

npx create-sanity@dev-preview

To upgrade a v3 Studio:

npm install [email protected]

Make sure your package.json are up to date with these dependencies:

{
  "dependencies": {
    // if you’re depending on `@sanity/ui`
    "@sanity/ui": "^1.0.0",
    "sanity": "3.0.0-rc.3"
  }
}

Breaking changes

Client dropped from configuration context

Removed the client property from configuration context. Use getClient({apiVersion: '2022-06-07'}) or similar instead.

Configuration resolution order

The order in which defineConfig resolves workspace configuration has changed.

Plugin configurations are now resolved before the configuration provided to defineConfig is applied.

The basic principle is that the higher index a plugin has in the plugins array, the higher priority it has, because it can "overwrite" what previous plugins have configured, or choose to pass it on in the chain. Finally, the chain ends in the "root config" (i.e. in defineConfig) which gets to determine the final output.

Before:

export default defineConfig({
  // rest of config...

  tools: (prev) => {
    // prev = [] 

    return [...prev, toolFromConfig]
  },

  plugins: [
    toolPlugin1(), // prev = [toolFromConfig]
    toolPlugin2(), // prev = [toolFromConfig, toolFromPlugin1]
    toolPlugin3(), // prev = [toolFromConfig, toolFromPlugin1, toolFromPlugin2]
  ],
})

After:

export default defineConfig({
  // rest of config...

  tools: (prev) => {
    // prev = [toolFromPlugin1, toolFromPlugin2, toolFromPlugin3]

    return [...prev, toolFromConfig]
  },

  plugins: [
    toolPlugin1(), // prev = []
    toolPlugin2(), // prev = [toolFromPlugin1]
    toolPlugin3(), // prev = [toolFromPlugin1, toolFromPlugin2]
  ],
})

Renamed modal option in document actions

In document actions, modal has been renamed to dialog.

Before:

export const MyDocumentAction = () => {
  // ... rest of the code

  return {
    // ... rest of the code
    modal: ActionDialog, // <--- This is the old way of doing it
    icon: RocketIcon,
    label: 'My action',
  }
}

After:

export const MyDocumentAction = () => {
  // ... rest of the code

  return {
    // ... rest of the code
    dialog: ActionDialog, // <--- This is the new way of doing it
    icon: RocketIcon,
    label: 'My action',
  }
}

Notable bugfixes

• Fixes an issue causing numeric array items to disappear when clearing the input
• Fixes an issue with arrays rendering inside custom blocks
• Makes sure colors used in the review changes panel will adjust to dark mode
• Fixes an issue causing media previews to not work properly
• Fixes a edge case where a cross-dataset reference to a deleted document would prevent you changing the document with the reference
• Fixes UI issues related to adding annotations in the Portable Text Editor.

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

🐛 Notable bugfixes

• Fixes an edge case where a cross dataset reference to a deleted document would prevent you from changing the referring document

📓 Full changelog

🐛 Notable bugfixes

• Fixes a typing issue introduced in the previous release (v3.0.0-rc.1)

📓 Full changelog

Features

• Workspaces can now be given a custom subtitle, and will not use the dataset name by default
• TypeScript is now the default option for new projects (you are still prompted to confirm - answering no will still give you a javascript project)

🐛 Notable bugfixes

• Fixes incorrect command in help text after initializing a new project
• Fixes typing of defineType not allowing specified components
• Fixes incorrect version being printed from sanity --version

📓 Full changelog

Sanity Studio v3: Release Candidate

This is the first Release Candidate of Sanity Studio v3. That means that you can expect APIs marked @public to be stable going forward. We are still ironing out bugs and making improvements, and appreciate any input or questions you might have.

We also want to invite you to a Sanity virtual event on December 8th, where we will dive into customer stories, demos, and talk about where the Sanity platform is headed.

You might also want to check out the notes for recent releases.

Installation and upgrading

To globally install/upgrade the v3 Sanity CLI:

npm install --global sanity@dev-preview

To validate you're on @3.0.0-rc.0:

$ sanity --version
> sanity version 3.0.0-rc.0

The new CLI should work with existing v2 studios, but you won't be able to initialize new v2 studios with it.

To initiate a new Studio without installing the CLI globally:

npx create-sanity@dev-preview

To upgrade a v3 Studio:

npm install [email protected]

Make sure your package.json are up to date with these dependencies:

{
  "dependencies": {
    // if you’re depending on `@sanity/ui`
    "@sanity/ui": "1.0.0-beta.32",
    "sanity": "3.0.0-rc.0"
  }
}

You might also have to upgrade your Sanity v3 plugins to their latest versions. The following command might be useful for checking for plugin updates:

npx npm-check-updates --target @studio-v3 --filter sanity

Breaking change: sanity start is now sanity dev

In Studio v2 and earlier developer preview releases, the command sanity start was used to start the development server. To better align with other frameworks such as Next.js, Remix, and Gatsby, we have renamed the command to sanity dev. The sanity start command is now used to start a static server that can be used to preview a production build (it is also available as sanity preview).

For existing studios, you might want to add a new dev npm script to your package.json file to make sure your team knows about the change:

{
  // ...
  "scripts": {
    "build": "sanity build",
    "dev": "sanity dev",
    "deploy": "sanity deploy",
    "start": "sanity start"
  }
}

Breaking change: createConfig is now defineConfig

To better align with other frameworks, we have renamed the following create-methods:

• createConfig -> defineConfig
• createCliConfig -> defineCliConfig
• createPlugin -> definePlugin

The old create-methods will still work for the time being, but are deprecated and will be removed prior to the final release of v3.

Beta: Add custom functionality to array inputs

It is now possible to customize the array input with custom functions. The API allows you to replace the Add button and exposes different methods through its properties for interacting with array content.

This feature also introduces breaking changes for callback namings and typings (see below).

Example of custom array functionality in defineConfig:

// sanity.config.ts

import {defineConfig, isArrayOfPrimitivesInputProps} from 'sanity'

function MyArrayFunction(props) {
  const {onItemAppend} = props

  const handleAdd = useCallback(() => {
    // Adds 'Hello!' to new string items in the array
    onItemAppend('Hello!')
  }, [onItemAppend])

  return <Button text={`Add "Hello!" to the array`} onClick={handleAdd} />
}

export default defineConfig({
  // ...,
  // other config
  form: {
    components: {
      input: (props) => {
        const {renderDefault}  = props

        // Check if the input is an array of primitives (strings etc)
        if (isArrayOfPrimitivesInputProps(props)) {
          return renderDefault({...props, arrayFunctions: MyArrayFunction})
        }

        return renderDefault(props)
      },
    },
  },
})

For feedback and questions on this API, go to GitHub Discussions.

Breaking change: Advanced input component callbacks

We've aligned our API naming policy for callbacks to be on<Subject><Verb>. For improved consistency, we have renamed the following callbacks:

• onFocusPath -> onPathFocus
• onCollapseFieldSet -> onFieldSetCollapse
• onExpandFieldSet -> onFieldSetExpand
• onCollapseField -> onFieldCollapse
• onExpandField -> onFieldExpand
• onOpenField -> onFieldOpen
• onOpenItem -> onItemOpen
• onCloseItem -> onItemClose
• onRemoveItem -> onItemRemove
• onPrependItem -> onItemPrepend
• onAppendItem -> onItemAppend
• onCollapseItem -> onItemCollapse
• onExpandItem -> onItemExpand
• onCreateValue -> onValueCreate

These callbacks are mostly used for complex custom object/array inputs.

Breaking change: Array functions components/types

We've improved "array functions" - see above. With this change comes a few naming changes:

• DefaultArrayOfPrimitivesFunctions -> ArrayOfPrimitivesFunctions
• DefaultArrayFunctions -> ArrayOfObjectsFunctions
• FormArrayInputFunctionsProps -> ArrayInputFunctionsProps

The default array functions components (ArrayOfPrimitivesFunctions and ArrayOfObjectsFunctions) are now exported from the sanity package.

All default input components are now exported

All the standard inputs are now exported and available in the sanity package for use when building custom input components.

Notable bugfixes

• Fixed an issue where the review changes panel might not use the selected document revision, and the content form would go into read-only mode

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

🐛 Notable bugfixes

• Fixes an issue with documents not loading when rxjs version 7 is installed as a dependency

📓 Full changelog

NOTE: with this release we highly recommend to upgrade @sanity/ui in package.json to:

"@sanity/ui": "1.0.0-beta.30"

✨ Highlights

At-a-glance

This version introduces several breaking changes that we are really excited to share with everyone:

• Improved Components API
• Consolidated sanity package and exports
• React 18 as new baseline version
• Removing the Schema namespace

These changes will make the Studio's customization API easier to discover and will vastly improve DX when implementing plugins and customizations moving forward.

NOTE: This release vastly reduces the number of breaking changes that will be introduced as we are getting closer to the first official stable v3 release.

Components API

We have made changes to the new Components API that allows a lot more flexibility in terms of wrapping, replacing, and modifying components in the Studio.

These components are now available for customization:

• Studio components: the general components of the studio. In this iteration, the components that can be customized are navbar, tool menu, layout and logo.
• Form components: field, input, item and preview.

Example:

import {createConfig} from 'sanity'

export default createConfig({
  // ...,

  form: {
    components: {
      field: MyField,
      input: MyInput,
      item: MyItem,
      preview: MyPreview,
    },
  },

  studio: {
    components: {
      layout: MyLayout,
      logo: MyLogo,
      navbar: MyNavbar,
      toolMenu: MyToolMenu,
    },
  },
})

The components available in this API are rendered using a middleware pattern. This means that plugin customizations are applied in a chain. Each plugin may call props.renderDefault(props) to defer to default rendering (this API was next(props) in 3.0.0-dev-preview.20).

What is renderDefault?

The props for each component available in the API includes a callback function called renderDefault. As the name implies, renderDefault renders the default component. When you call renderDefault, you also pass the props needed to render the default component, and these props can be modified. In the example below, we create a custom tool menu plugin that filters out the vision tool when the studio is running in non-development mode:

import {useMemo} from 'react'
import {
  ToolMenuProps,
  createConfig,
  createPlugin,
  isDev,
} from 'sanity'

// Plugin's `ToolMenu` component
function MyToolMenu(props: ToolMenuProps) {
  const {renderDefault, tools} = props
    
  const filteredTools = useMemo(() => {
    return isDev ? tools : tools.filter((t) => t.name !== 'vision')
  }, [isDev, tools])

  return renderDefault({
    ...props,
    tools: filteredTools, // Pass the custom array of tools
  })
}

// Plugin
const toolPlugin = createPlugin({
  name: 'tool-plugin',
  studio: {
    components: {
      toolMenu: MyToolMenu,
    },
  },
})

// Config
export default createConfig({
  ...,
  name: 'studio-config',
  plugins: [toolPlugin()],
})

If yet another plugin makes customizations of toolMenu – then the props received in that plugin will be the result of the previous customization (that is, no vision tool in non-development mode).

NOTE: If renderDefault is not called, the middleware chain stops and the next plugin will have no effect.

Using renderDefault in schema

The renderDefault function may also be used directly in a schema definition to render a default component. In the example below, we create a component that renders the default string input with a character counter, directly in the schema:

import {Stack, Text} from '@sanity/ui'
import {defineField, StringInputProps} from 'sanity'

function StringInputCharacterCount(props: StringInputProps) {
  return (
    <Stack space={2}>
      {/* Render the default string input */}
      {props.renderDefault(props)}

      <Text align="right" size={1}>
        Characters: <strong>{props.value?.length || 0}</strong>
      </Text>
    </Stack>
  )
}

export const myDocument = defineField({
  type: 'document',
  name: 'myDocument',
  fields: [
    {
      name: 'title',
      type: 'string',
      title: 'Title',
      components: {
        input: StringInputCharacterCount,
      },
    },
  ],
})

Result:

Consolidated sanity package and exports

Breaking changes to export bundles

The sanity package is now split up into these export bundles:

• sanity
• sanity/cli
• sanity/desk
• sanity/router

There have been necessary changes made in order to make the exports clean and independent bundles: no API member is now exported twice (as was the case before). And there are no longer cyclic dependencies between exports.

Why? These changes are mainly introduced to prevent API confusion.

// Before: this is not great
import {Chunk} from 'sanity'
import {Chunk} from 'sanity/desk'
import {Chunk} from 'sanity/form'

// Now: an API member is only available in one of the exports
import {Chunk} from 'sanity'

This also means we have removed duplicate code in the export bundles, which could cause issues with React contexts and bundle size.

API release tags

All the API members in the sanity package now have API release tags. These are TSDoc release tags that are understood by Intellisense and can be seen in your IDE.

Example:

How to reason about the various tags:

React 18

The Studio internals are upgraded to React 18 and use the new concurrent renderer. Support for React v17 is dropped and v18 is the new baseline in order to make full use of the new features and performance improvements.

Why we're doing this now

Structured content creation should be a delightful and exceptional experience. Everything should feel responsive. That means the UI needs to keep up with your interactions no matter what. If 300 people are editing the same document as you are and your phone's CPU just can't keep up that's ok. Everyone else's changes can wait for a second or two before they show up. As long as you can type as fast as you want without ever feeling held back by a sluggish text field that struggles to keep up with your thoughts. The edits of your peers have time to render whenever you stop to gather your thoughts. It's more important for you to stay in the zone, and for the studio to prioritize responding to your interactions.

With new APIs like startTransition, useTransition, useDeferredValue and Suspense we can start moving towards making this vision a reality.

While it is possible to do this in a way that gives theoretical support for both react v17 and v18, we ultimately decided against it after a thorough evaluation with the goal of maintaining compatibility with v17. It came down to which option allow us to deliver the highest quality product, and unless everything is tested on both versions of react for every release we'll either:

• Have good v17 support but unable to adopt v18 features that can't be shimmed on v17. Such as startTransition, useTransition and useDeferredValue.
• Great v18 support but the v17 becomes increasingly buggy and slow as devs become used to how v18 behaves. For example v18 automatically batches state updates while v17 does not. A component that in v18 have few re-renders might have a ton of re-renders in v17 if the component author isn't aware of this difference and there's great v17 testing routines in place.

Upgrade info

Official guide: https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#updates-to-client-rendering-apis
If you're on react v17 today and don't see any warnings in your console when running your studio locally then upgrading is pretty much just a matter of bumping react, react-dom and react-is to ^18 in your package.json.

Read the official upgrade guide to get a sense of what components you might need to give a little refactor.
While migrating studio internals we found that if there's a problem in a component it's usually related to one of these factors:

• A class component that is using lifecycle method with a UNSAFE_ prefix, for example UNSAFE_componentWillMount or UNSAFE_componentWillReceiveProps. Detailed guide.
• The component had useEffect logic that assumed that useEffect(() => () => teardown(), []) the teardown() is only called once, and on unmount. Get a refresher on how useEffect works to make it easier to find and resolve these bugs.
• Incorrect dependency arrays in hooks like useEffect, useMemo, useCallback and such either because they were suppressed in the linter due to // eslint-disable or custom hooks and layers of abstractions made the linter unable to detect them.
• If you're on TypeScript and are seeing a lot of typing errors you can try the automated migration script. Or hold off on upgrading @types/react until you have the bandwidth to fix the problems that the stricter typings uncover in your code.

@sanity/ui

If you have a dependency on @sanity/ui and use it in your project make sure to bump it to v1 as it's upgraded to support the new concurrent renderer.

Other changes

renderStudio now returns a function for unmounting it, to make it easier to use in other libraries such as vue, svelte, solid, angular, jqueryui, mootools, whatever floats your boat. How about as a Web Component? ⛵

<script type="module">
import {createConfig, renderStudio} from 'sanity'
import {deskTool} from 'sanity/desk'

customElements.define(
  'sanity-studio',
  class extends HTMLElement {
    connectedCallback() {
      const config = createConfig({
        projectId: this.getAttribute("projectId"),
        dataset: this.getAttribute("dataset"),
        plugins: [deskTool()],
        schema: {
          types: []
        }
      })

      this.unmount = renderStudio(this, config)
    }

    disconnectedCallback() {
      this.unmount?.()
    }
  }
)
</script>

<sanity-studio projectId="pnkijp0b" dataset="codesandbox"></sanity-studio>

See Codesandbox with example using Sanity Studio v3 in a web component.

React Strict Mode

You can opt-in to React's Strict Mode checks for your custom studio components in these ways:

• Add reactStrictMode: true to your sanity.cli.ts file.
• Create a .env.development file and add SANITY_STUDIO_REACT_STRICT_MODE=true to it.
• Set the env var while starting sanity: SANITY_STUDIO_REACT_STRICT_MODE=true sanity start

We strongly suggest you opt-in to better prepare your custom studio for the future of React. This only affects development mode, production mode or sanity build is unaffected by this setting.

Schema namespace removed

The Schema namespace has been removed. The same types can now be accessed as regular imports from the sanity package.

// Before
import {Schema} from 'sanity'

const stringDef: Schema.StringDefinition = {...}

// Now
import {StringDefinition} from 'sanity'

const stringDef: StringDefinition = {...}

With this change it is now be possible to augment definition interfaces using declaration merging. This allows us to improve typesafety and intellisense in defineType schema helpers for plugins moving forward.

See TSDoc on defineType for examples on this.

Support for v2 theming

import {buildLegacyTheme} from 'sanity'

export default createConfig({
  // ... studio config ...
  
  theme: buildLegacyTheme({
    // here you can add CSS properties that
    // were used to customize Studio v2 theming
    '--black': '#000',
    '--default-button-color': '#666',
    // etc
  })
})

Improved search 🕵️

• Adds support for filtering search results by any number of document types. You can also browse documents from any number of types without entering a search query.
• Search is now toggleable with a hotkey (Command/Control-K) and fully navigable by keyboard.
• Recent searches (including selected document types) are stored for later use
• Search terms and results are retained upon close: handy if you want to quickly revisit or amend your last search
• Improves performance when rendering and scrolling through large result sets
• The search dialog is wider, giving you more space for the search result listing

NOTE: Documents listed in search results will no longer resolve custom components for block content and array views

Slug functions context

Slug options source and slugify are now passed a context parameter as the last argument. It contains getClient, schema and currentUser.

🐛 Notable bugfixes

• The Studio now includes global CSS with font-family, and will no longer use serif in cases where you don't use <Text> from @sanity/ui.
• Various minor bug fixes in the Portable Text Editor.
• Fixes various bugs related to React 18 support.
• Adds strict validation of predefined list options for array types.
• Fixes various issues with array inputs and makes sure all variations of array inputs have parity with v2.

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

✨ Highlights

Shared Content

This release introduces support for shared content through cross-dataset references. Read more in the announcement: https://www.sanity.io/blog/shared-content-introduction

Improved search

Order search results by relevance, created and last updated date.

🐛 Notable bugfixes

• Fixes an issue where split panes might not persist after reloading the studio
• Fixes a bug causing revision history selector to always display the current version instead of the selected revision

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

🐛 Notable bugfixes

• Fixes an issue causing content to be inserted twice when using custom paste handler

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

✨ Highlights

Performance improvements

This release includes several performance fixes that should now make the Studio more responsive while editing documents. (See more details in individual PRs #3668, #3662, #3660)

Improved search

Search for documents containing an exact phrase by wrapping text inside double quotes.

Other features

• Upgrade @sanity/ui to v.0.37.22

🐛 Notable bugfixes

• Fixes an issue where the scroll position in global search wasn’t being correctly retained in some instances.
• Fixes an issue in global search that would cause the studio to crash if Local Storage is unavailable.

📓 Full changelog

🐛 Notable bugfixes

• Fixes an issue where the vision plugin would crash when attempting to switch API versions

📓 Full changelog

🐛 Notable bugfixes

• Fixes an issue where typescript projects would be initialized with an incorrect compile target, leading to dev server not starting

Other features

• Brought CLI commands up to date with v2 variants, adding --force flags where missing

📓 Full changelog

Upgrade the Command Line Interface (CLI) with:

npm install --global @sanity/cli

Upgrade Sanity Studio with:

sanity upgrade

✨ Highlights

New CLI flags!

We've added a few new flags to make automation easier!

The --force flag was added to a few already existing commands and will skip the confirmation prompt and proceed with the command:

sanity dataset alias unlink <alias-name> --force

sanity dataset alias delete <alias-name> --force

sanity dataset delete <dataset-name> --force

sanity graphql undeploy --dataset <dataset-name> --force

When added, the --no-open flag prevents the login page from automatically opening in the browser.

sanity login --provider <provider-name> --no-open

📓 Full changelog