refactor(config): standardize the workspace on serde_yaml_ng for YAML parsing#1447
Conversation
This was referenced May 19, 2026
This was referenced May 19, 2026
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
🟢 🤖 Continuous IntegrationWonderful, this rule succeeded.
🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR descriptionWonderful, this rule succeeded.
|
sileht
previously approved these changes
May 20, 2026
eb8ab2e to
64b2cf0
Compare
2cd6b4f to
5cd88c9
Compare
Member
Author
Revision history
|
… parsing
The workspace had two YAML parsers — both forks of the archived
`dtolnay/serde-yaml`. `mergify-config` used `serde_norway` for
`.mergify.yml`; `mergify-ci` used `serde_yaml_ng` for merge-queue
metadata in PR bodies and git notes. Same job, two crates, two
transitive `unsafe-libyaml*` trees in Cargo.lock.
Standardize on `serde_yaml_ng` for both. The decision is grounded
in concrete signal, not vibe:
Metric serde_norway serde_yaml_ng
───────────────────────── ───────────── ─────────────
Reverse-deps on lib.rs 229 (78 dir.) 618 (349 dir.)
GitHub stars 53 109
Last commit 2025-08-04 2025-09-14
Bus factor (recent prs) 1 (solo) merges externals
Maintainer statement v0.9.40 title README: explicit
"I'm gonna upstream-compat
maintain this" intent
unsafe-libyaml backend forked ("…- canonical
norway")
Open since 2024-06-10 2024-05-03
License Apache-2.0 MIT (= upstream)
`serde_yaml_ng` wins on every axis that matters for the "will this
still be alive in two years" question: three-times the ecosystem
adoption, more recent activity, accepts third-party PRs, declares
the maintenance commitment in writing, and uses the canonical
`unsafe-libyaml` rather than a parallel-fork backend.
Functional surface is identical for both of our use shapes —
`from_str` to a typed struct for ci, `from_str` to `Value`
then convert to `serde_json::Value` for config validation.
Migration is purely a rename at the one call site.
Cargo.lock drops `serde_norway` and `unsafe-libyaml-norway`.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Change-Id: If5d28d2c4259127181bace5bafb0ac02c78d8f7b
64b2cf0 to
a27051b
Compare
5cd88c9 to
8468caf
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The workspace had two YAML parsers — both forks of the archived
dtolnay/serde-yaml.mergify-configusedserde_norwayfor.mergify.yml;mergify-ciusedserde_yaml_ngfor merge-queuemetadata in PR bodies and git notes. Same job, two crates, two
transitive
unsafe-libyaml*trees in Cargo.lock.Standardize on
serde_yaml_ngfor both. The decision is groundedin concrete signal, not vibe:
Metric serde_norway serde_yaml_ng
───────────────────────── ───────────── ─────────────
Reverse-deps on lib.rs 229 (78 dir.) 618 (349 dir.)
GitHub stars 53 109
Last commit 2025-08-04 2025-09-14
Bus factor (recent prs) 1 (solo) merges externals
Maintainer statement v0.9.40 title README: explicit
"I'm gonna upstream-compat
maintain this" intent
unsafe-libyaml backend forked ("…- canonical
norway")
Open since 2024-06-10 2024-05-03
License Apache-2.0 MIT (= upstream)
serde_yaml_ngwins on every axis that matters for the "will thisstill be alive in two years" question: three-times the ecosystem
adoption, more recent activity, accepts third-party PRs, declares
the maintenance commitment in writing, and uses the canonical
unsafe-libyamlrather than a parallel-fork backend.Functional surface is identical for both of our use shapes —
from_strto a typed struct for ci,from_strtoValuethen convert to
serde_json::Valuefor config validation.Migration is purely a rename at the one call site.
Cargo.lock drops
serde_norwayandunsafe-libyaml-norway.Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com
Depends-On: #1446