This guide is for site operators: people who install plugins into a site. If you write plugins, see Migrating to the plugin CLI instead.
Upgrade your dependencies
Update emdash and your plugin packages to their latest versions, then reinstall and rebuild:
pnpm up --latest emdash @emdash-cms/plugin-audit-log @emdash-cms/plugin-webhook-notifier @emdash-cms/plugin-atproto
pnpm build
After upgrading, your site may build and run without further changes. If the build fails or a plugin stops loading, work through the breaking changes below. Each one tells you exactly what to change.
For the full list of changes in each package, see its entry on the releases page.
Breaking changes
Changed: three first-party plugins use a default export
Earlier releases exposed first-party plugins as a named export and a factory call, for example import { auditLogPlugin } from "@emdash-cms/plugin-audit-log" used as auditLogPlugin().
These plugins now provide a default export that you pass directly into plugins: or sandboxed:. There is no factory call. This affects @emdash-cms/plugin-audit-log, @emdash-cms/plugin-webhook-notifier, and @emdash-cms/plugin-atproto.
What should I do?
In astro.config.mjs, drop the braces around the import and the () after the plugin name.
The following example shows the change for @emdash-cms/plugin-audit-log, which runs in-process and goes in plugins::
import { auditLogPlugin } from "@emdash-cms/plugin-audit-log";
import auditLog from "@emdash-cms/plugin-audit-log";
export default defineConfig({
integrations: [
emdash({
plugins: [auditLogPlugin()],
plugins: [auditLog],
}),
],
});
Apply the same two edits to the other packages. @emdash-cms/plugin-atproto and @emdash-cms/plugin-webhook-notifier are sandboxed plugins, so they go in sandboxed: instead of plugins:; the import change is identical.
| Package | Default export binding |
|---|---|
@emdash-cms/plugin-audit-log | auditLog |
@emdash-cms/plugin-webhook-notifier | webhookNotifier |
@emdash-cms/plugin-atproto | atproto |
This change applies only to the three packages listed above. Other native plugin imports may keep
their existing shape. For example, Field Kit remains fieldKitPlugin() under plugins: []; follow
each native plugin’s installation instructions.
After upgrading
If a third-party plugin still ships a named export and factory call, it has not been updated for this release. Check its changelog. All first-party plugins listed above use the default-export shape.