The crates
| Crate | What it is | Where |
|---|---|---|
noyalib |
The YAML 1.2 parser and serialiser, with serde and the lossless editor | crates.io · docs.rs · source |
noyalib-serde-yaml |
The drop-in serde_yaml replacement: rename the package, change nothing |
crates.io · source |
noya-cli |
noyafmt and noyavalidate, as signed binaries, a container and Homebrew, Scoop and AUR packages |
crates.io · source |
noyalib-lsp |
The language server for VS Code, Zed, Neovim and any other client | crates.io · source |
noyalib-mcp |
The Model Context Protocol server for AI agents, also on npm and as a container | crates.io · npm · source |
noyalib-wasm |
The parser compiled to WebAssembly, published on npm | crates.io · npm · source |
Each repository has its own manual, built from the same sources as its README: noyalib, noyalib-serde-yaml, noya-cli, noyalib-lsp, noyalib-mcp and noyalib-wasm.
The lockstep rule
Every crate carries the same version number, and every companion depends on the core with an exact pin. A release is one event across six repositories: the core is tagged and published first, then each companion swaps its pre-release git reference for the crates.io version and publishes. A script refuses the tag while any reference still points at a branch.
The rule exists so that "which version do I have" has one answer. A fix in the parser reaches the CLI, the editor, the agent and the browser in the same release, and a report against any of them names the same core.
The same tests, everywhere
The core passes the 406 cases of the official YAML test suite. Since
September 2026 every companion runs those cases through its own entry point
as well: the CLI's exit code, the language server's diagnostics, the MCP
tool result, the shim's from_str and the WebAssembly JSON model. The first
run found two real defects, in the language server and the MCP server, and
both were fixed before the next release. The
conformance page records the current numbers.
What is shared
The six repositories share their CI workflows, pulled from the core at a pinned commit: licence and dependency audits, supply-chain vetting, unused dependency checks, REUSE compliance, strict docs, signature verification and the test matrix. A change to a gate lands once and reaches every repository when it re-pins.
They also share the community files: code of conduct, governance, support policy, security policy and citation metadata. The ecosystem document in the core is the full account, including a scorecard of all six.