The four registerXxxPlugins entry points have divergent shapes and none self-activate — users must both register in code and set the HOCON plugin key (footgun #377). DX unification:
activate (builder withActivate, default true) on the Register*PluginsOptions composites: register + set the active journal/snapshot in one call; an explicit HOCON key still wins.
- Top-level
withUrl/withPoolConfig on the composite (merged onto every leaf like the existing shared withPool), so the URL is written once.
- Uniform return
PersistenceHandles { journal?, snapshotStore?, durableStateStore?, close() } for all four.
- New
registerSqlitePlugins + plugin id (SQLite is the only backend with no registration story) with its own XOptions family.
- Complete src/config/ConfigKeys.ts with the postgres/mariadb/sqlite plugin ids + durable-state keys; have PersistenceExtension read via ConfigKeys instead of string literals.
- Add a Postgres example and an end-to-end register+config integration test (currently none).
Depends on #377. Part of Phase 3.
The four registerXxxPlugins entry points have divergent shapes and none self-activate — users must both register in code and set the HOCON plugin key (footgun #377). DX unification:
activate(builderwithActivate, default true) on the Register*PluginsOptions composites: register + set the active journal/snapshot in one call; an explicit HOCON key still wins.withUrl/withPoolConfigon the composite (merged onto every leaf like the existing shared withPool), so the URL is written once.PersistenceHandles { journal?, snapshotStore?, durableStateStore?, close() }for all four.registerSqlitePlugins+ plugin id (SQLite is the only backend with no registration story) with its own XOptions family.Depends on #377. Part of Phase 3.