feat(core): explicit plugins.register API (replaces no-op autoLoad/directory)

[lane711]

Summary

• Adds plugins.register?: Plugin[] to SonicJSConfig so user plugins are mounted by createSonicJSApp directly — no more wrapping the core app in a custom Hono() instance just to attach plugin routes.
• Marks plugins.directory / plugins.autoLoad as @deprecated no-ops. They were declared in the type but never wired up; bootstrap only iterated the hardcoded core plugin registry, so user plugins silently failed to load.
• New mountPlugin() helper (packages/core/src/plugins/mount.ts) sorts middleware by priority, then mounts routes. User plugins are registered before /admin/plugins and the /admin catch-all so plugin admin pages aren't shadowed.

Why explicit, not filesystem autoload

SonicJS runs on Cloudflare Workers — no runtime fs, so any directory autoload would have to be a build-time Vite plugin. That's a lot of machinery for two lines of saved code, and most mature plugin ecosystems (Vite, Astro, Fastify, Nuxt modules) landed on explicit register: [...] arrays for the same reasons: type-safety, tree-shaking, debuggability, and the ability to pass config (weatherPlugin({ apiKey })) inline.

Originated from a Discord report: a user couldn't get a custom plugin to load with autoLoad: true. The flag did nothing.

Before / after (starter app)

// before — manual Hono wrapper, manual route loop
const coreApp = createSonicJSApp(config)
const app = new Hono()
if (contactFormPlugin.routes) {
  for (const route of contactFormPlugin.routes) app.route(route.path, route.handler)
}
app.route('/', coreApp)
export default app

// after
export default createSonicJSApp({
  collections: { autoSync: true },
  plugins: { register: [contactFormPlugin] },
})

Test plan

• npx vitest run in packages/core — 1479 passed, 328 skipped, 0 failed
• New mount.test.ts covers route mounting, multi-route, global vs scoped middleware, priority ordering, and empty-plugin no-op (6 tests)
• npx tsc --noEmit in packages/core is clean
• packages/stats still compiles (disableAll: true path unchanged)
• Visual smoke test of starter template + a custom plugin in dev — recommended before merging

🤖 Generated with Claude Code

[furelid]

disableAll’s documented contract looks broader than the implementation.

The comment here says this disables all non-core plugins, but config.plugins.register plugins are mounted separately and explicitly bypass the mountPluginManagerRoutes() gating path. In other words, with disableAll: true, user-registered plugins still mount.

Relevant implementation:

• gating logic: packages/core/src/app.ts:184-202
• direct user-plugin mounting: packages/core/src/app.ts:394-399

Could we either:

1. make disableAll apply to plugins.register too, or
2. narrow this comment so it clearly only applies to plugins routed through the manager/gating path?

As written, the public API is a bit surprising.

[furelid]

The docs for disableAll don’t match the implementation.

Here it says “Disable all plugins (including core)”, but createSonicJSApp() explicitly keeps core plugins enabled:

• packages/core/src/app.ts:109-110
• packages/core/src/app.ts:184-186

So today the actual behavior is closer to “disable non-core plugins routed through the manager,” not “including core”.

I think this should be corrected before merge so users don’t get the opposite behavior from what the docs promise.

[furelid]

Requesting changes for disableAll semantics before merge.

Right now there are two mismatches:

1. plugins.register plugins still mount even when disableAll: true
2. the docs say disableAll disables core plugins, but the implementation explicitly keeps core plugins enabled

I’d suggest either making behavior match the docs, or tightening the docs/comments so they match the actual implementation.