How Sanity plugins work
Plugins are written with the definePlugin function, which accepts most of the same properties as defineConfig. Every plugin definition has a required name property that identifies the plugin. A plugin cannot set the workspace-level settings dataset, projectId, auth or theme.
definePlugin can also take a function instead of an object, which lets plugin users pass options to a configuration factory. Many plugins take configuration options as an argument when they are called in the plugins array. A plugin can include other plugins, so features can be layered on top of each other. Sanity documents the API in its Studio plugins guide.
Finding, building and choosing plugins
Sanity lists official and community plugins on the Sanity Exchange. The @sanity/color-input plugin, for example, adds a color schema type and a color picker input to the Studio.
To build your own, Sanity recommends @sanity/plugin-kit for publishing plugins; it scaffolds and verifies the package and builds it with @sanity/pkg-utils. A new plugin package is scaffolded with the plugin-kit init command. During development, the link-watch script rebuilds the plugin on change and publishes it to a local yalc repository for testing in a Studio.
A plugin has to be compatible with the Studio version in use. Some older plugin versions were built for Studio v2 and do not work with current studios. Plugins with heavy dependencies can make the Studio bundle larger. Moving features into plugins keeps sanity.config.ts small and makes the configuration portable.
For how the Studio fits into the rest of the platform, read what Sanity is, and for a side-by-side with Payload, see Payload vs Sanity. For a custom Studio build, see Pagepro's Sanity development services.
Sources
- Studio pluginsSanity · sanity.io
- Plugins APISanity · sanity.io
- Installing and configuring pluginsSanity · sanity.io
- Developing pluginsSanity · sanity.io