Plugins should be able to declare collections and taxonomies in their descriptor

[treeslikemedia]

Problem

When building a sandboxed plugin that needs its own structured content (e.g. "Listings", "Events", "Recipes" — any domain-specific post type), there's currently no way for the plugin to declare these as proper EmDash collections in its descriptor.

PluginDescriptor.storage only creates plugin-scoped storage (ctx.storage). These don't appear in the admin content editor, don't support drafts/revisions/SEO, and don't get the built-in list/edit UI that proper collections receive.

The only way to create collections and taxonomies today is via the site's .emdash/seed.json, which means:

• Plugin users must manually configure schema before the plugin works
• • There's no "install and go" experience from the Dashboard (related: fix(tests): use global hookTimeout for integration test beforeAll hooks #125 - The plugin can't be self-contained

Proposal

Add optional collections and taxonomies fields to PluginDescriptor (or PluginDefinition), using the same shape as SeedCollection and SeedTaxonomy:

export interface PluginDescriptor {
  // ... existing fields ...

  // Collections the plugin needs (applied during plugin:install)
  collections?: SeedCollection[];

  // Taxonomies the plugin needs (applied during plugin:install)
  taxonomies?: SeedTaxonomy[];
}

During plugin:install, EmDash would apply these like a seed — creating the collections/taxonomies if they don't already exist (using onConflict: "skip" semantics so they don't clobber user customizations).

The plugin would then access its content via the existing ctx.content API (with read:content / write:content capabilities), which already works.

Example

export const descriptor: PluginDescriptor = {
  id: "my-plugin",
  version: "0.1.0",
  capabilities: ["read:content", "write:content"],

  collections: [
    {
      slug: "listings",
      label: "Listings",
      labelSingular: "Listing",
      icon: "layout-list",
      supports: ["drafts", "revisions", "search", "seo"],
      fields: [
        { slug: "title", label: "Title", type: "string", required: true },
        { slug: "price", label: "Price", type: "integer" },
        { slug: "content", label: "Description", type: "portableText" },
      ],
    },
  ],

  taxonomies: [
    {
      name: "listing_category",
      label: "Listing Categories",
      hierarchical: true,
      collections: ["listings"],
    },
  ],
};

Why this matters

Without this, any plugin that needs structured content has to either:

1. Use plugin storage and rebuild the entire content editor UI from scratch (no drafts, no revisions, no SEO, no built-in admin)
2. Require users to manually configure their seed file before the plugin works

Neither of these is the WordPress-like "install and go" experience that makes plugin ecosystems thrive.

[ascorbic]

This is a good idea, and I did identify this as a missing part. I would also like the abiity for plugins to add system fields to content types too

[rob-j-oliver]

+1 the abiity for plugins to add system fields to content types!

[syhily]

I think this is a missing feature for developing some plugins like post-views or post-likes. Hope to see this soon.

[fatihkisa]

I'm building a giveaway plugin and hit the exact same issue. My plugin needs /picker, /dashboard, /result/[id] pages that can't live in the plugin today. Would gladly help test a PR for this if someone picks it up.