plugin-loader
| Placement | compiled-in (in-process) |
| Source | github.com/opencharly/charly/candy/plugin-loader |
| Version | 2026.192.0000 |
| Candy | plugin-loader |
This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.
Providers
Section titled “Providers”The reserved words this plugin serves:
loader— loader class
What it does
Section titled “What it does”The unified-config LOADER’s PARSE half, relocated out of charly core into a compiled-in plugin candy (P6) — the config front-end every command reaches before any project is read. A compiled-in plugin candy is a SEPARATE Go module importing only sdk (never charly core), so it cannot produce charly’s typed *UnifiedFile (which embeds the core Config mechanism + the runtime Candy graph the plan keeps in core). So the boundary is PARSE/MATERIALIZE: this plugin PARSES the project (file read → import resolution → YAML multi-doc → the #NodeDoc CUE gate → reserved-word node decomposition → discover walk) into a generic, sdk-expressible ParsedProject (kind-keyed opaque nodes + the resolved import/discover structure); the HOST MATERIALIZES the typed *UnifiedFile from it (the kind-blind materializer stays core, consuming the generic tree exactly as the per-node structural-kind fold already does). The bootstrap SEED (registry_bootstrap.go init → the embedded providers: manifest via a plain yaml.Unmarshal) STAYS core and never calls LoadUnified, so a compiled-in loader plugin has NO bootstrap cycle. COMPILED-IN (in the embedded compiled_plugins:), registered at init() before the first LoadUnified call; unlocks alternative config front-ends.
See also the candy reference for this candy’s install surface.