Roadmap
This page is the product-facing view of where the JOC Ecosystem is and where it’s going. Engineering detail: repository ROADMAP.md and ecosystem governance.
Composition without coupling. Independent packages first; shared infrastructure only when experience proves it.
Where we are
JayOnCode™ has a signed governance model: four packages live on npm, no premature shared core, one new flagship at a time, and platform work closed until real pain appears.
| Package | Focus | Status |
|---|---|---|
@jayoncode/browser-lifecycle | Session signals — visibility, idle, connectivity, cross-tab | Live on npm |
@jayoncode/form-intelligence | Headless form workflows — validation, rules, drafts, wizards | Live on npm |
@jayoncode/object-diff | Deep diff, change records, JSON Patch | Live on npm |
@jayoncode/storage | Policy-driven client persistence — adapters, TTL, migrations | Live on npm |
Each ships with docs, SemVer/Changesets, and an interactive playground.
Phase snapshot
| Phase | Status |
|---|---|
| 1–5 Foundation → Architecture Convergence | Complete (ADRs Accepted; zero Extract) |
| 6 Selective Shared Infrastructure | Blocked |
| 7 Developer Tooling | Usable (pnpm joc) |
| 8 Ecosystem Expansion | Storage shipped (@jayoncode/storage@0.1.0); next package TBA |
| 9 Integration & Adoption | Kickoff bar met |
| 10 Platform Evolution | Closed |
Near term
- Polish live packages — APIs, budgets, adapters, playground fidelity (including Storage).
- Composition DX — composition guide, recipes, examples.
- Landing — docs home +
apps/websiteroute to docs/playgrounds. - Next flagship — announce and incubate only when a brief is accepted (one at a time).
Next packages (ecosystem expansion)
New @jayoncode/* libraries are to be announced. Each must answer why it deserves to exist (problem, audience, alternatives, playground plan, non-goals) before scaffolding — and only one flagship incubates at a time. See ecosystem governance.
Longer-term vision
JOC should feel like a cohesive toolkit of independent libraries:
- One mental model: headless TypeScript cores + thin framework adapters
- Install only what you need; tree-shake the rest
- Docs and playgrounds that make adoption boringly predictable
- Room to grow new problem spaces without breaking package boundaries
We are not building a single mega-framework or UI kit. A shared platform appears only if real multi-package pain demands it.
How priorities are chosen
- Real consumer pain over novelty
- Clear package boundaries over “just add it to an existing library”
- Docs/playground readiness as part of “done”
- SemVer honesty — additive APIs preferred; breaks are rare and called out
Shape the roadmap
- Open an issue or discussion for proposals
- Read Contributing before large PRs
- Track package-level plans in each package’s docs and changelog
Bottom line: Governance is public under engineering/ecosystem/ — four packages are live on npm; Storage (0.1.0) completed Phase 8 incubation.