DaisyConfig

Typed YAML Layer

DaisyConfig owns typed YAML, managed lifecycle, and the production path for config-heavy plugins.

Use DaisyConfig when YAML shape, versioning, missing-key merge, reload safety, and shared settings-plus-lang ownership are the real engineering problem.

Depends on DaisySeries + DaisyCore to complete the normal runtime flow.

Install DaisyConfig Managed YAML Files

Typed mappingReplace scattered getters with codec-driven config objects.

Managed lifecycleCreate defaults, merge missing keys, and run ordered schema migrations with version-aware writeback.

Module bundlesOwn settings.yml plus lang.yml together through one managed module handle.

DaisyCore text bridgeStore text here, render it there, and keep Placeholder-aware rendering inside DaisyCore.

Selective config scopeDaisyConfig grows where repeated config lifecycle pain exists, not where every config-adjacent helper could be wrapped once.

What DaisyConfig handles

Codec-driven config

Map YAML into real objects with explicit shape, path-aware validation, and DaisySeries-backed value codecs.

Unmanaged YAML

Keep the low-level DaisyYaml and simple handle path when one file and one codec are enough.

Managed YAML

Own config_version, default-file creation, missing-key merge, ordered migrations, and last-good runtime preservation.

Module bundles

Load modules/<category>/<module>/settings.yml plus lang.yml as one typed settings-and-text unit.

The rule is deliberate: DaisyConfig owns typed YAML and lifecycle. It does not try to become a parser layer, renderer, or generic utility bucket just to feel broader.

What DaisyConfig does not handle

No placeholder execution

DaisyConfig stores text and config data only. It does not call PlaceholderAPI or run a second render pipeline.

No viewer-aware rendering

DaisyCore still owns MiniMessage parsing, viewer-aware rendering, and runtime UI behavior.

No parser ownership

DaisySeries still owns canonical keys, aliases, and value parsing rules for the broader modern Paper value surface, including materials, sounds, biomes, attributes, difficulties, particles, and more.

Related Product

DaisyConfig depends on DaisySeries for canonical value decoding

Managed settings still decode modern Paper values through DaisySeries instead of copying parser rules locally.

Open DaisySeries docs

Related Product

DaisyConfig depends on DaisyCore for runtime rendering

Managed lang files are still data. DaisyCore still parses MiniMessage, resolves viewers, and renders the final output.

Open DaisyCore docs

Best first path

1

Install DaisyConfig and define the config shape

Start with Install DaisyConfig and then build your first typed config.

2

Move to managed YAML when file lifecycle becomes real

Use Managed YAML Files when config versioning, missing-key merge, or startup migration safety matter more than raw file loading.

3

Adopt module bundles when settings and lang already travel together

Use Module Bundles for modules/<category>/<module>/settings.yml plus lang.yml, with one reload/migrate path and one text source.

4

Pair DaisyConfig with DaisyCore only when runtime rendering is already real

Use Use DaisyConfig with DaisyCore when the same plugin already needs runtime UI plus stored text.

Quick links

• Start here: Install DaisyConfig
• Managed path: Managed YAML Files
• Migrations: YAML Migrations
• Registry: Module Registry
• End-to-end example: Example Plugin Walkthrough
• DaisyCore bridge: Use DaisyConfig with DaisyCore
• Migration guide: From Plugin-Local Config Loaders