ConfigKit's simple Load accepts one strict YAML source (or explicit defaults-only input). LoadLayered additionally combines explicit lower-priority source groups with an independently selected main input. Sources can be host files, native fs.FS files, labeled bytes or readers, or snapshotted mappings. Enabled path and glob imports compose strictly within their group; precedence between groups combines mappings recursively. Both entry points return a complete, validated configuration with detached metadata and safe diagnostics. Applications may perform audited defaulting and normalization through a resolver, then report domain errors and warnings through read-only semantic validation. Secret tags and a path predicate drive deterministic redacted effective YAML. Typed secret references resolve environment names before validation, and explicit secrets-directory bootstrap is available as a separate startup operation. Explicit CLI override records apply above overlays. Value explanation is available through detached structured records and deterministic redacted output. Built-in extends relationships let a mapping inherit from a named sibling during the same load, retaining explicit presence and source/derivation history. The root Diff API compares frozen effective values from two successful same-type loads; the configuration contract and consumer guide describe its safe changed-region records and maintained workflows.

Sources can also be explicitly placed as sequence items, and definitions can register selected sequences to append records with distinct string IDs during strict composition. Higher-priority sequences still replace lower-priority sequences as whole values. See the sequence contract, maintained prompt example, and ADR 0014.

type Config struct {
    Enabled bool `yaml:"enabled"`
    Workers int  `yaml:"workers"`
}

func ReadConfig(path string) (Config, error) {
    result, err := configkit.Load[Config](configkit.File(path))
    if err != nil {
        return Config{}, err
    }
    return result.Config, nil
}

Design philosophy

ConfigKit favors one coherent, predictable configuration model over flexibility for reproducing each consumer's conventions. Its goal is to let applications load once, inspect where final values came from, and distinguish explicit values from omissions with minimal configuration bookkeeping. Applications retain their domain rules and execution responsibilities.

Loading is synchronous and complete on return. Applications normally load once near startup and then use the final configuration and metadata; ConfigKit stays inactive until explicitly called again. Applications may initiate additional loads as needed. See the loading lifecycle for completion and ownership details.

Within a configuration tier, independent contributions compose strictly: shared mappings combine, while overlapping non-mapping definitions are errors. Between precedence tiers, mappings combine recursively, retaining omitted lower-priority children; other values replace lower-priority values. The main document and its imports form one strictly composed tier. Explicit underlay groups sit below it and above typed defaults; a selected overlay and explicit CLI overrides sit above it. The configuration contract owns the detailed combination rules and input-specific constraints. At definition-registered paths only, strict composition can append records with distinct explicit IDs; ordinary and unregistered sequences keep their conflict or whole-value replacement behavior.

The architecture goals explain these priorities and how genuine new needs can justify extending the shared model. The future feature list preserves candidates for consideration in future releases.

The configuration contract describes implemented behavior, including input destinations. The consumer adoption guide provides maintained simple, layered, mounted-collection, and identified-prompt examples alongside the migration shapes. Input placement decisions are recorded in ADR 0011 and sequence placement and composition in ADR 0014. See the development guide for repository orientation and the release procedure for maintainer-only candidate and publication steps.

ConfigKit code is licensed under the LGPL v3.0 or later.

Open Source attribution notices are available.