sanity-default-plugins

作者: sanity-io

使用单体仓库的默认插件约定创建并连接Sanity核心插件。在添加、修改或审查插件时使用…

npx skills add https://github.com/sanity-io/sanity --skill sanity-default-plugins

Sanity Core Plugin

Start Here

Before adding a core plugin, read the sanity-plugin-authoring skill at ../sanity-plugin-authoring/SKILL.md to understand the general Sanity plugin API and what plugins can provide. Then inspect nearby plugins and these files:

  • packages/sanity/src/core/config/resolveDefaultPlugins.ts
  • packages/sanity/src/core/config/types.ts
  • packages/sanity/src/core/config/studio/types.ts
  • A similar plugin under packages/sanity/src/core/*/plugin/

The new plugin should be added inside core so it can be imported into the default plugins.

Prefer local patterns over new abstractions.

Plugin Shape

Use definePlugin and export a stable internal name constant:

import {definePlugin} from '../../config/definePlugin'

export const FEATURE_NAME = 'sanity/feature'

export const feature = definePlugin({
  name: FEATURE_NAME,
  studio: {
    components: {
      layout: FeatureStudioLayout,
    },
  },
  i18n: {
    bundles: [featureUsEnglishLocaleBundle],
  },
})

Use ../../config/definePlugin when matching existing internal plugin files. ../../config is also available in some folders.

Locale Resources

Default core plugins that render UI text should add a locale resource bundle. Follow the pattern from packages/sanity/src/core/singleDocRelease:

  • packages/sanity/src/core/<feature>/i18n/index.ts: exports the locale namespace, US English bundle, and resource key type.
  • packages/sanity/src/core/<feature>/i18n/resources.ts: exports default locale strings and keyof resource type.
  • packages/sanity/src/core/<feature>/plugin/index.ts: imports the bundle and registers it under i18n.bundles.

Example i18n/index.ts:

import {type LocaleResourceBundle} from '../../i18n'

export const featureNamespace: 'feature' = 'feature'

export const featureUsEnglishLocaleBundle: LocaleResourceBundle = {
  locale: 'en-US',
  namespace: featureNamespace,
  resources: () => import('./resources'),
}

export type {FeatureLocaleResourceKeys} from './resources'

Example i18n/resources.ts:

const featureLocaleStrings = {
  'action.example': 'Example',
}

export type FeatureLocaleResourceKeys = keyof typeof featureLocaleStrings

export default featureLocaleStrings

Example plugin registration:

import {featureUsEnglishLocaleBundle} from '../i18n'

export const feature = definePlugin({
  name: FEATURE_NAME,
  i18n: {
    bundles: [featureUsEnglishLocaleBundle],
  },
})

Default Plugin Wiring

Default core plugins are listed in resolveDefaultPlugins.ts.

  1. Import the plugin and its name constant.
  2. Add the plugin to defaultPlugins(options) in the desired composition order.
  3. If gated, add a plugin.name === FEATURE_NAME branch in getDefaultPlugins.
  4. Add any required options to DefaultPluginsWorkspaceOptions in types.ts.
  5. In getDefaultPluginsOptions, build default plugin options directly from workspace config defaults and spreads. Do not call config property reducers here; reducers belong to resolved source/workspace config, while default plugin options are a lightweight workspace-level input for plugin insertion.
  6. Update packages/sanity/src/core/config/__tests__/resolveConfig.test.ts with focused default plugin tests:
    • The plugin is not added by default.
    • The plugin is added when the proper config flag is enabled.
  7. Add ordering coverage when plugin order affects UI composition.

Example default option shape:

variants: {
  enabled: false,
  ...workspace.beta?.variants,
}

Remember: user plugins are appended before default plugins in prepareConfig.tsx, then the component middleware chain reverses flattened config order. Check the existing chain before relying on wrapper order.

Verification

For default plugin changes, run:

pnpm vitest run --project=sanity packages/sanity/src/core/config/__tests__/resolveConfig.test.ts

Also run lint/read diagnostics for edited files. Add component-level tests only when the plugin changes runtime rendering beyond insertion.

来自 sanity-io 的更多技能

tdd
sanity-io
采用红绿重构循环的测试驱动开发。当用户希望使用TDD构建功能或修复缺陷、提及“红绿重构”、希望……时使用。
performance-optimization
sanity-io
优化应用程序性能。当存在性能要求、怀疑性能回归,或核心网页指标及加载时间……时使用。
content-experimentation-best-practices
sanity-io
结构化指导,用于设计、执行和分析内容实验,以提升转化率和参与度。涵盖假设框架、指标选择、样本量计算以及A/B和多变量实验中的统计显著性检验。包含关于p值、置信区间、功效分析和贝叶斯方法的详细资源,用于解读结果。提供CMS集成模式,用于在字段级别管理变体并连接外部...
content-modeling-best-practices
sanity-io
结构化内容建模指南,涵盖模式设计、可复用性及多渠道交付。核心原则包括:将内容视为数据而非页面、维护单一事实来源、面向未来渠道设计、优化编辑工作流。提供引用与嵌入对象的选择框架、关注点分离及内容复用模式。包含扁平化、层级化及分面分类法的分类学指导。适用于...
portable-text-conversion
sanity-io
将HTML和Markdown内容转换为适用于Sanity的Portable Text块。在从旧版CMS迁移内容、将HTML或Markdown导入Sanity时使用。
portable-text-serialization
sanity-io
将Portable Text渲染并序列化为React、Svelte、Vue、Astro、HTML、Markdown和纯文本。在任意前端中实现Portable Text渲染时使用…
sanity-best-practices
sanity-io
Sanity CMS开发的全面最佳实践与集成指南,涵盖多种框架及主题。包含10余种框架集成方案,如Next.js、Nuxt、Astro、Remix、SvelteKit和Angular,并提供框架专属模式与配置指导。同时涵盖模式设计、GROQ查询优化、可视化编辑、便携文本、图像处理、TypeGen、本地化及内容迁移等主题指南。提供快速参考结构,可根据任务类型仅加载相关指南。
sanity-migration
sanity-io
规划、实施并审查从其他CMS和内容系统迁移至Sanity的过程。适用于从AEM、Adobe Experience Manager、Contentful、Strapi、Webflow、WordPress、Payload、Drupal、Markdown/MDX/frontmatter文件、WXR/XML导出、CMS API、数据库转储、静态HTML进行迁移或平台重构,或设计数据提取、转换、Portable Text转换、资产迁移、重定向、验证及切换工作流时使用。
data-analysisdatabasedevelopment