Migrating to noyalib

This is the umbrella index for migrating to noyalib from every actively-published Rust YAML crate. Each link goes to a standalone, self-contained guide with TL;DR diff, function table, behavioural notes, and migration checklist.

Crates.io / docs.rs state verified 2026-09-05. If the upstream API has shifted since, file an issue at https://github.com/sebastienrousseau/noyalib/issues and we’ll update.

Coming from serde_yaml and want zero source changes? Rename the package and keep every call site:

serde_yaml = { package = "noyalib-serde-yaml", version = "=0.0.52" }

noyalib-serde-yaml is the behavioural serde_yaml 0.9 shim, released in lockstep with the core. The guides below are for moving to the native API.

Pick your starting crate

Already on noyalib from before the v0.0.12 workspace split? That move is covered separately in MIGRATION-WORKSPACE-SPLIT.md.

What to expect from noyalib regardless of source crate

Across every guide, three behavioural notes recur. They each default to safer / stricter behaviour than serde_yaml 0.9 and its forks; opt-outs are documented per guide.

1. Value::Tagged is preserved through the Value data path. from_str::<Value>("!Custom 'hi'\n") returns Value::Tagged(t) (t.tag() == "!Custom", t.value() == Value::String("hi")). Typed targets (#[derive(serde::Deserialize)] struct Foo { … }) still see through the tag transparently — the preservation only affects the dynamic Value path.
2. YAML 1.2 strict booleans by default. country: NO parses as Value::String("NO"), not Value::Bool(false). Opt into YAML 1.1 boolean recognition via ParserConfig::new().legacy_booleans(true) if you need the old behaviour for round-trip compatibility with legacy files.
3. Multi-doc streams use load_all_as. noyalib::load_all_as::<T>(input)? returns a Vec<T> directly. The Deserializer::from_str(...).map(...) pattern from serde_yaml and its forks collapses to this one entry point.

What noyalib adds (no equivalent in any of the eight)

• noyalib::from_str_strict::<T> — error on unknown keys.
• noyalib::Spanned<T> — source-location wrapper for typed fields. (yaml-spanned covers a similar use case for the dynamic path; noyalib covers both dynamic and typed.)
• noyalib::cst::Document — lossless byte-faithful edits with comment / whitespace preservation.
• noyalib::ParserConfig / noyalib::SerializerConfig — unified, fluent-builder configuration covering every per-call toggle.
• noyalib::validate_against_schema — JSON Schema 2020-12 validation against the parsed document.
• noyalib::compat::serde_yaml — name-for-name re-export shim for the most common in-flight use serde_yaml::*; pattern, with no transitive serde_yaml 0.9 dependency.
• A set of binaries: noyafmt (formatter), noyavalidate (schema validator + auto-fixer), noyalib-mcp (Model Context Protocol server for AI tooling), noyalib-lsp (Language Server Protocol implementation).

What noyalib does not do (yet)

• No equivalent to serde-saphyr’s strict panic-free-by-construction proof — noyalib’s defence is #![forbid(unsafe_code)] plus the resource-limit gates, not formal verification.
• No streaming Deserializer you can next() event-by-event from user code — noyalib::Deserializer is a serde-trait driver, not an event iterator.
• No equivalent to serde-yaml-bw’s Value::Alias variant — noyalib resolves aliases at parse time per YAML 1.2 §7.1.

If your migration runs into a shape we don’t cover, file an issue at https://github.com/sebastienrousseau/noyalib/issues with the upstream crate version and the input that misbehaves.