Rubric Formats

Rubric — Formats

Rubric ships three format adapters. You pick one per @Config (via @Config#format), and the runtime picks the right adapter as long as the ConfigIO it was handed knows about that format.

Format	Comments	Trailing commas	Ecosystem support	Notes
TOML	Yes (preserved)	No	Best-of-three for hand-edited configs	Default. Recommended unless you have a reason otherwise.
JSON5	Yes	Yes	Wide (parsers everywhere)	Human-friendly JSON.
JSON	No	No	Universal	Only if you must — comments carry your @Comment metadata into the file.

Wiring an IO with your format

Rubric's rubric-loader-common module (transitively pulled in by both rubric-fabric and rubric-neoforge) exposes a RubricSerialization factory:

• RubricSerialization.defaultIO() — TOML only.
• RubricSerialization.allFormatsIO() — TOML + JSON + JSON5.
• RubricSerialization.io(Map<Format, FormatAdapter>) — custom set.

Rubric's static entry point takes the ConfigIO at bootstrap. Import Loaders from your loader's integration package (com.oliveryasuna.mc.rubric.fabric.Loaders on Fabric, com.oliveryasuna.mc.rubric.neoforge.Loaders on NG):

Rubric.bootstrap(RubricSerialization.allFormatsIO(), Loaders.platform());

If you pick a format the IO doesn't know about, manager.load() throws:

java.io.IOException: No FormatAdapter registered for JSON

If you hit this, either broaden the IO (allFormatsIO()) or change the config's @Config#format back to something the IO already supports.

Format-specific notes

TOML

Backed by night-config's TOML module. Comments from @Comment are written above the entry and preserved on save. Sections become sub-tables.

JSON

Plain JSON via night-config. No comment support — @Comment values are still tracked in the schema (and shown as tooltips in the GUI), just not persisted to the file. Recommended when the file is machine-consumed and human-editing is not a priority.

JSON5

Backed by Jankson. Comments preserved. Trailing commas allowed. A good middle ground when you want JSON's ubiquity but hand-editing comfort.

Adding a custom adapter

Implement com.oliveryasuna.mc.rubric.io.FormatAdapter:

public interface FormatAdapter {
    ValueTree parse(byte[] bytes) throws SerializationException;
    byte[] write(ValueTree tree, Schema schema) throws SerializationException;
}

Register the adapter into a FileConfigIO:

final Map<Format, FormatAdapter> adapters = new HashMap<>();
adapters.put(Format.TOML, new TomlFormatAdapter());
adapters.put(Format.HOCON, new MyHoconAdapter());  // your custom Format value
final ConfigIO io = RubricSerialization.io(adapters);
Rubric.bootstrap(io, Loaders.platform());

The Format enum ships with TOML / JSON / JSON5 today. If you need a format that isn't in the enum, wait for a Rubric release that adds it (or open a PR / issue).

Custom scalar types (Mojang Codec<T> bridge)

Beyond the format-level adapter, you may need Rubric to know how to encode a specific type — say, net.minecraft.resources.ResourceLocation. Two options:

1. Implement ValueCodec<T> and register it via CodecRegistry.registerCustom(Class, ValueCodec). Straight and simple.
2. Bridge a Mojang Codec<T> via the rubric-mojang-codec module. MojangCodecBridge.bridge(Codec<T>) returns a ValueCodec<T> you can register. Useful when Mojang or a mod already provides a Codec<T> for the type.

Each loader integration ships its own Loaders factory (com.oliveryasuna.mc.rubric.fabric.Loaders / com.oliveryasuna.mc.rubric.neoforge.Loaders). Both expose registerMcCodecs(CodecRegistry) which wires common Minecraft types (ResourceLocation, UUID, etc.) into a registry — call it once at bootstrap.