Roadmap
The public OmniSvelte roadmap — current status and what's coming next.
OmniSvelte Strategic Roadmap
Consolidated roadmap merging the existing
packages/core/README.mdroadmap (v0.1–v1.0) with every feature, primitive, and integration discussed in the remote-functions/architecture review offeat/omni-cli. This supersedes the checklist-only version as the working planning document.
Mission
Make OmniSvelte the framework of choice for building anything with web technology — web, mobile, and desktop — by collapsing the repetitive 80% of full-stack work (CRUD, auth, validation, realtime, payments, jobs, forms) into typed primitives, so developers spend their time on the 20% that's actually their product's business logic.
How to read this document
Every feature is scored on four axes so you can sequence work by leverage, not just by what's interesting to build:
0. Codebase audit — what's actually true today
Before planning new work, here's what direct inspection of feat/omni-cli confirmed, since the existing roadmap's checkboxes aren't fully accurate:
- Genuinely solid: the
Model/QueryBuilder/relationships layer, schema → Drizzle/Zod codegen, Better-Auth integration, the Vite plugin's virtual modules ($db,$models/*,$auth/*), and the core CLI (init,add,generate schema|migration,db push|pull|generate|migrate|check|studio|seed,ui init|add,doctor,install-dependency). - Scaffolded but inert: cache (Redis/filesystem drivers warn-and-noop), queue (same), mail (no provider sends anything), storage (no driver stores anything), notifications (no DB persistence), and the
resource/auth-page/emailgenerators (console.log('...coming soon')). - ✅ OmniPlugin API: The
OmniPlugininterface is fully typed and available. The Plugin Ecosystem phase is unblocked. - Not present at all yet: no
.remote.tsfiles anywhere in the repo — none of the SvelteKit remote-functions work from this conversation has been started.
1. Core primitives reference
Most features below are combinations of a small set of building blocks. Get these right once and everything downstream gets cheaper.
2. Master feature tables
A. Core ORM & Data Layer
B. Remote Functions Integration (the API layer)
C. Auth & Authorization
D. Realtime & Live Data
E. Caching
F. Background Jobs & Scheduling
G. Storage & Media
H. Notifications & Communication
I. Payments, Billing & Generic Webhooks
J. AI & Intelligence Layer 🆕 (entirely new category)
K. Local-First & Cross-Platform 🆕 (entirely new category)
L. Business-Logic Primitives 🆕 (entirely new category)
M. Developer Experience & Testing 🆕 (entirely new category, distinct from the old roadmap's ">90% framework test coverage" goal)
N. CLI & Code Generation
O. UI, Forms & Admin
P. Plugin Ecosystem
Q. Observability & Monitoring
R. Platform Polish 🆕
S. Deployment, Docs & Release Readiness
3. Versioned timeline
Estimates assume continued part-time, largely solo development alongside coursework and competitions — treat dates as relative pacing, not commitments. Each version keeps the original roadmap's scope and folds in this conversation's additions where they belong.
4. Prioritization methodology
Value was scored by how directly a feature removes repetitive, non-business-logic work (the stated mission), not by novelty. Effort was scored by how much net-new design is required versus how much can be assembled from primitives that already exist. Two things consistently pushed a feature up in priority regardless of effort: (1) it fixes something broken rather than something merely missing, and (2) it's a primitive other planned features depend on (e.g. resource() and query.live unlock several other rows in these tables, so they're worth doing early even though they're not the cheapest items).
5. Risks & dependencies
- Plugin ecosystem has a cold-start problem. A marketplace and community plugins are worthless without a few flagship first-party plugins to prove the pattern — sequence v0.8 accordingly.
- Bus factor. The roadmap above is intentionally sequenced so that fixing and finishing (v0.2–v0.9) come before expanding (v1.1+), so the framework is usable and credible even if later phases slip.
- CrossWS maturity — the realtime plan leans on it for full WebSocket support;
query.live/SSE are reasonable fallbacks if it proves too heavy. - Differentiation vs. crowded competition (Next.js, Remix, Laravel, SvelteKit alone) — the AI-native and local-first primitives are the parts of this roadmap with the least direct competition; they're worth protecting from scope creep into "yet another generic full-stack framework."
6. Success metrics
- Time-to-first-working-CRUD-app for a new developer (target: under 10 minutes from
omni initto a working model + form + list page). - Number of production apps built on OmniSvelte.
- Community plugin count and contributor count once v0.8 ships.
- npm weekly downloads / GitHub stars as a lagging adoption signal — useful, but secondary to the above.
7. Immediate next actions
- Build
resource(Model)for remote-function CRUD generation — the single primitive most other items depend on. - Implement one real cache driver (Redis) and one real storage driver (S3) — closes the gap between "the API exists" and "it actually works," and unblocks file uploads and durable caching simultaneously.
- Write the Remote Function wrappers to ensure config and middleware behavior is scalable.
- Ship the
Moneyvalue type and foundational plugin groundwork — small effort, highly reusable.
8. Opportunities for Improvement 💡
- DevTools Suite: A comprehensive local dashboard (similar to Prisma Studio or Nuxt DevTools) running on a separate port during development. It will provide:
- Database Explorer: Visually inspect, filter, and edit records in your local DB without writing SQL.
- Remote Functions Panel: Track all incoming
query,form, andcommandcalls from the client, including payload sizes and execution times. - Background Jobs Monitor: Watch your queues (BullMQ/in-process) in real-time, retry failed jobs, and inspect job arguments.
- Events & Hooks Tracing: See exactly which model hooks fired during a transaction.
- First-Class Edge Support: Ensuring the framework and its data fetching primitives adhere strictly to WinterCG standards, enabling deployment to Cloudflare Workers or Vercel Edge seamlessly.
- Marketplace Tooling: Standardizing the plugin publishing process so developers can safely distribute and monetize high-quality OmniSvelte plugins.