2.1 KiB
2.1 KiB
plug
Type-only sketch for a cleaner plugin architecture.
This folder is intentionally not wired into the application yet. It exists so the shape of a redesign is easy to inspect without mixing design work with runtime changes.
Files
common.tsshared helper types used by the rest of the sketchspec.tsplugin declaration and normalization typespackage.tspackage metadata and capability inspection typesmodule.tsimported module shape and validation typesexternal.tsexternal plugin load pipeline typesmeta.tsplugin metadata store typesinstall.tsinstall and config patch workflow typesserver.tsserver plugin service typestui.tsTUI plugin manager service types
Reading order
If you want the sketch to build up from small concepts to runtime orchestration, read the files in this order:
spec.tsStart here for the basic nouns: plugin kinds, sources, declarations, config origins, and normalized candidates.package.tsNext read how package metadata is described after a plugin target has been resolved.module.tsThen read the imported module shapes and validation results for v1 and legacy modules.external.tsThis is the shared external loading pipeline that connects spec parsing, package inspection, and module import.meta.tsRead this next to see what state should be persisted across runs and why it belongs behind a service.install.tsThis describes the install, manifest, and config patch workflow shared by CLI and TUI.server.tsRead the server runtime service after the lower-level pipeline files, since it mainly composes those pieces.tui.tsRead this last because it has the largest runtime surface and depends on most of the earlier concepts.common.tsThis file is only shared utility typing. You can skim it first or ignore it until you see a helper type you want to expand.
Intent
- Stateful parts are described as service interfaces.
- Stateless parts are described as function types returning
Effect. - The comments explain what each type is for and where it would sit in the architecture.