Plugin Layer Reference

For app builders, start here instead:

• Plugin Interface — the canonical reference for SlingshotPlugin authoring
• Package-First Authoring — the parallel tier for app-side feature composition

This page is the deep-dive on what the plugin layer does internally.

The short version

• definePackage — declarative app-side feature composition (your blog, your billing module).
• SlingshotPlugin — imperative framework-level plugin authoring (auth, persistence, queues, custom middleware).

Both are first-class. Pick by the shape of what you are building. See Composing an App for the decision guide.

What the plugin layer is for

SlingshotPlugin is the contract for:

• framework-level infrastructure (auth, persistence, queues, search, mail)
• async bootstrap with lifecycle handoff between phases
• registrar registrations (route auth, actor resolver, rate limit adapter, fingerprint builder, cache adapters, email templates)
• conditional middleware that needs to mount based on resolved config
• cross-cutting concerns like metrics, tracing, custom logging

The lifecycle

Plugins still run through these phases:

1. setupMiddleware
2. setupRoutes
3. setupPost
4. teardown

That contract still matters. It just should not be the first thing most users learn.

How this relates to packages

createApp() compiles packages into framework plugins internally.

That is why the docs now separate:

• public package authoring
• lower-level plugin lifecycle reference

Next

• Plugin Interface — full SlingshotPlugin reference
• Package-First Authoring — the parallel tier for app-side feature composition
• Lower-level Seams — overrides and manual wiring inside the package model