31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
# Oikos Modularization Backlog
|
|
|
|
Status: low priority roadmap item.
|
|
|
|
## Goal
|
|
|
|
Convert Oikos from module-shaped code into a proper modular platform where users and contributors can add, remove, and customize modules without editing core router/navigation/settings files in several places.
|
|
|
|
## Desired outcome
|
|
|
|
- A single module manifest/registry owns route, navigation, icon, theme, stylesheet, settings visibility, permissions, and API capability metadata.
|
|
- New modules can be added by creating a module folder plus manifest entry, not by touching many core files.
|
|
- Existing modules can be disabled cleanly at UI and API/capability level.
|
|
- Language packs can be added by dropping in a locale file and registering display metadata in one place.
|
|
- Deployment-specific or family-specific customizations stay outside upstreamable core code.
|
|
|
|
## Candidate implementation tasks
|
|
|
|
1. Introduce a module registry, for example `public/modules/manifest.js` or a JSON manifest loaded during boot.
|
|
2. Refactor `router.js` to build routes, navigation order, primary nav, theme accents, and disabled-module guards from the registry.
|
|
3. Move Kitchen tabs to module metadata so grouped/submodules are first-class.
|
|
4. Add a server-side module/capability registry for API exposure and OpenAPI grouping.
|
|
5. Add a locale registry so `SUPPORTED_LOCALES`, locale picker labels, and service-worker precache entries are generated from one source.
|
|
6. Define an extension/overlay mechanism for local deployments without patching core files.
|
|
7. Add contributor docs: “Create a module” and “Add a language pack”.
|
|
8. Add regression tests that verify module registration, hiding/disabling, navigation, and locale discovery.
|
|
|
|
## Priority
|
|
|
|
Low. Do after the current Kitchen / Meal Planning work is stable and after Friborg-specific customizations are separated from upstreamable platform code.
|