Benchmarks

Speed, memory, spec-conformance, and bundle size for Lightning YAML against the other parsers this repo benchmarks itself against: js-yaml, yaml (eemeli), and the JSON baseline where a workload is JSON-shaped enough for it to compete. Use the “On this page” panel to jump between sections; each metric shows the latest run, the trend over time, and a full breakdown by workload. Every section below states its own measurement’s date, source commit, and (where the suite records one) environment — sections come from different published runs, so this page never shows one line for all of them.

How to read these numbers

Every figure on this page — and everywhere else on this site (the homepage, any “N× faster” figure) — is a single real measurement in the environment it’s labelled with. Nothing here is ever averaged or blended across environments: a browser’s engine and Node are different machines with different results, and combining them into one number would hide that. Where more than one environment has published results, use the picker below to see each engine’s own numbers; a ratio’s popover elsewhere on the site lists each engine’s own measured value the same way.

Right now, results come from node 24.21.0 (x64-linux), chromium 141.0.7390.37 (x64-linux), webkit 26.0 (x64-linux). As a new environment — a browser engine, a different Node version — starts publishing benchmark runs, it adds its own rows and its own picker option; it never changes the numbers already shown for an environment that was already publishing.

A few notes on the charts themselves:

• Bar charts (latest run) scale each workload row to its own slowest parser, so compare bars within a row, not across rows. Speed bars are labelled with time relative to the fastest parser in that row (×); memory bars are labelled with the absolute peak RSS.
• Trend charts (over time) render one document per published run, oldest to newest. Absolute nanoseconds drift with CI-runner noise, so the speed trends plot a machine-invariant ratio-to-fastest on a log axis; memory, conformance, and bundle size are stable, so they trend as absolute values. Hover any point for its date, value, and — where the run recorded one — the library version; a ringed point marks a version change.
• Every chart is a static image — inline SVG rendered at build time, no client JavaScript.

These numbers track real runs, not a hand-captured snapshot: CI publishes each run to the orphan benchmark-data branch, and the deploy workflow overlays that history at build time — the bar charts render the newest published document per suite, the trend charts the full history. To reproduce them yourself, see running the benchmarks & tests.

The speed charts below (Parse speed, Stringify speed) were measured in more than one runtime — pick one; it applies to both sections:

node 24.21.0 (x64-linux)chromium 141.0.7390.37 (x64-linux)webkit 26.0 (x64-linux)

Parse

Turning YAML text into JavaScript values — the hot path for most consumers.

Parse speed

Measured on AMD EPYC 9V45 96-Core Processor (~3.76 GHz) · node 24.21.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Measured in chromium 141.0.7390.37 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Measured in webkit 26.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Parse time by workload

Lower is better. Each workload is scaled to its own slowest parser; labels show time relative to the fastest parser in that row (×). Exact avg ns per parse() call is in the breakdown below.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Parse time by workload

Lower is better. Each workload is scaled to its own slowest parser; labels show time relative to the fastest parser in that row (×). Exact avg ns per parse() call is in the breakdown below.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Parse time by workload

Lower is better. Each workload is scaled to its own slowest parser; labels show time relative to the fastest parser in that row (×). Exact avg ns per parse() call is in the breakdown below.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Parse time vs fastest, run over run — large-records

Lower is better, log scale. Each parser's time as a multiple of the fastest in the same run (×) — machine-invariant. The fastest sits at 1× by construction; a rising Lightning YAML line would mean a regression.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Parse time vs fastest, run over run — large-records

Lower is better, log scale. Each parser's time as a multiple of the fastest in the same run (×) — machine-invariant. The fastest sits at 1× by construction; a rising Lightning YAML line would mean a regression.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Parse time vs fastest, run over run — large-records

Lower is better, log scale. Each parser's time as a multiple of the fastest in the same run (×) — machine-invariant. The fastest sits at 1× by construction; a rising Lightning YAML line would mean a regression.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Full breakdown — every workload, avg ns per parse() call (— where a library can’t read that workload):

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	2.76 µs	6.34 µs	24.0 µs	285 µs
medium-records	321 µs	584 µs	2.38 ms	34.7 ms
large-records	3.62 ms	6.74 ms	34.2 ms	434 ms
xlarge-records	37.1 ms	79.1 ms	370 ms	3.98 s
medium-nested	637 µs	1.07 ms	4.26 ms	60.5 ms
large-nested	4.68 ms	7.74 ms	35.2 ms	438 ms
Plain block YAML
yaml-plain-small-records	—	7.69 µs	25.3 µs	328 µs
yaml-plain-medium-records	—	886 µs	2.88 ms	45.8 ms
yaml-plain-large-records	—	8.96 ms	35.9 ms	481 ms
yaml-plain-medium-nested	—	470 µs	1.39 ms	17.7 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	12.8 µs	38.5 µs	438 µs
yaml-rich-medium	—	954 µs	2.83 ms	33.4 ms
yaml-rich-large	—	9.16 ms	29.8 ms	471 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	2.00 µs	6.43 µs	22.3 µs	242 µs
medium-records	215 µs	625 µs	2.16 ms	22.4 ms
large-records	2.71 ms	7.07 ms	26.3 ms	271 ms
medium-nested	441 µs	1.06 ms	3.57 ms	39.4 ms
large-nested	3.49 ms	7.99 ms	29.6 ms	273 ms
Plain block YAML
yaml-plain-small-records	—	9.06 µs	24.4 µs	215 µs
yaml-plain-medium-records	—	1.05 ms	2.61 ms	33.5 ms
yaml-plain-large-records	—	10.6 ms	31.9 ms	324 ms
yaml-plain-medium-nested	—	550 µs	1.16 ms	12.7 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	15.6 µs	33.3 µs	300 µs
yaml-rich-medium	—	1.18 ms	2.66 ms	26.3 ms
yaml-rich-large	—	10.6 ms	29.5 ms	351 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	1.91 µs	5.53 µs	21.9 µs	219 µs
medium-records	250 µs	459 µs	2.14 ms	25.6 ms
large-records	2.86 ms	4.87 ms	27.0 ms	376 ms
medium-nested	344 µs	916 µs	3.77 ms	39.2 ms
large-nested	2.56 ms	6.04 ms	27.4 ms	378 ms
Plain block YAML
yaml-plain-small-records	—	6.58 µs	24.5 µs	237 µs
yaml-plain-medium-records	—	734 µs	3.06 ms	32.4 ms
yaml-plain-large-records	—	7.31 ms	33.1 ms	428 ms
yaml-plain-medium-nested	—	387 µs	1.25 ms	12.4 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	11.0 µs	36.7 µs	351 µs
yaml-rich-medium	—	818 µs	2.97 ms	28.9 ms
yaml-rich-large	—	7.95 ms	30.4 ms	368 ms

Parse memory

Measured on AMD EPYC 9V45 96-Core Processor (unknown) · node 24.21.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Peak memory by workload (parse)

Lower is better. Whole-process peak resident set (process.resourceUsage().maxRSS) in isolated child processes, fixed at 25 iterations. Each workload is scaled to its own heaviest parser.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Peak memory, run over run — xlarge-records

Lower is better. Absolute peak resident set size (MB) — peak RSS is the stable memory figure, so unlike speed it is shown absolute. One document per published run, oldest to newest.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Full breakdown — every workload, peak RSS (MB):

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	97.1 MB	79.5 MB	77.9 MB	83.4 MB
medium-records	79.2 MB	83.6 MB	99.2 MB	290 MB
large-records	101 MB	145 MB	384 MB	654 MB
xlarge-records	390 MB	568 MB	1149 MB	2706 MB
medium-nested	80.1 MB	82.4 MB	134 MB	318 MB
large-nested	102 MB	115 MB	362 MB	646 MB
Plain block YAML
yaml-plain-small-records	—	79.2 MB	79.6 MB	81.6 MB
yaml-plain-medium-records	—	83.4 MB	91.5 MB	291 MB
yaml-plain-large-records	—	126 MB	356 MB	542 MB
yaml-plain-medium-nested	—	83.1 MB	91.2 MB	162 MB
Rich YAML (anchors + !!binary)
yaml-rich-small	—	80.0 MB	79.7 MB	82.8 MB
yaml-rich-medium	—	85.8 MB	96.9 MB	258 MB
yaml-rich-large	—	115 MB	312 MB	513 MB

Parse memory — in-browser (ratio)

The chart above measures Node; a browser page can’t read its own process’s memory the same way, so this is a separate, ratio-only measurement taken inside real browser engines — always relative to Lightning YAML (1.0×), never absolute megabytes. Two methods that ask different questions, so they are not comparable to each other or to the Node figures above:

• Chrome’s engine (Chromium) — how much of the page’s own JS heap the parsed results still hold, measured in-page and garbage-collected before each reading. This is the narrower question: it counts what the result retains, and is blind to memory the parse allocated and handed straight back.
• Safari’s engine (WebKit) — the operating system’s peak memory reading for the browser’s page process across the same parse-and-keep step. Broader, and noisier: it does catch memory spent during the parse, but also engine overhead that has nothing to do with the parser.

Read the Chromium table below expecting a tie on the bigger files, because that is what the narrower question is bound to answer: past a certain size the bytes still held are the parsed values themselves, and all three parsers build the same values from the same document. Where these libraries genuinely differ is the memory spent during the parse — the Node chart above.

Chrome's engine · memory retained by the parsed result

Measured in chromium 141.0.7390.37 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Workload	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
Plain block YAML
yaml-plain-small-records	1.0×	1.2×	1.6×
yaml-plain-medium-records	1.0×	1.0×	1.0×
yaml-plain-large-records	1.0×	1.0×	1.0×
Rich YAML (anchors + !!binary)
yaml-rich-small	1.0×	0.9×	1.7×
yaml-rich-medium	1.0×	1.0×	1.0×
yaml-rich-large	1.0×	1.0×	1.0×

Safari's engine (WebKit) · peak memory of the page process

Measured in webkit 26.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Workload	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
Plain block YAML
yaml-plain-small-records	1.0×	1.3×	10×
yaml-plain-medium-records	1.0×	2.2×	3.1×
yaml-plain-large-records	1.0×	2.9×	3.7×
Rich YAML (anchors + !!binary)
yaml-rich-small	1.0×	0.9×	3.8×
yaml-rich-medium	1.0×	1.4×	2.6×
yaml-rich-large	1.0×	2.0×	3.2×

Stringify (dump)

Serializing JavaScript values back to YAML text.

Stringify speed

Measured on AMD EPYC 9V45 96-Core Processor (~3.76 GHz) · node 24.21.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Measured in chromium 141.0.7390.37 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Measured in webkit 26.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Stringify time by workload

Lower is better. Each workload is scaled to its own slowest dumper; labels show time relative to the fastest in that row (×). Exact avg ns per stringify() call is in the breakdown below.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• js-yaml (tuned) 5.4.3
• yaml (eemeli) 2.9.0

Stringify time by workload

Lower is better. Each workload is scaled to its own slowest dumper; labels show time relative to the fastest in that row (×). Exact avg ns per stringify() call is in the breakdown below.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• js-yaml (tuned) 5.4.3
• yaml (eemeli) 2.9.0

Stringify time by workload

Lower is better. Each workload is scaled to its own slowest dumper; labels show time relative to the fastest in that row (×). Exact avg ns per stringify() call is in the breakdown below.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• js-yaml (tuned) 5.4.3
• yaml (eemeli) 2.9.0

The js-yaml (tuned) series is the same library dumping with the lean CORE schema instead of its heavyweight default (YAML 1.1 plus timestamp/binary/omap/set). On JSON-shaped data that runs faster and round-trips identically — so it, not the default, is the fair yardstick for how fast js-yaml can stringify this data. It appears only where the data is JSON-shaped; the rich workloads genuinely need the full schema, where the “tuned” config would be identical to the default.

Stringify time vs fastest, run over run — large-records

Lower is better, log scale. Each dumper's time as a multiple of the fastest in the same run (×) — machine-invariant. The fastest sits at 1× by construction; a rising Lightning YAML line would mean a regression.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• js-yaml (tuned) 5.4.3
• yaml (eemeli) 2.9.0

Stringify time vs fastest, run over run — large-records

Lower is better, log scale. Each dumper's time as a multiple of the fastest in the same run (×) — machine-invariant. The fastest sits at 1× by construction; a rising Lightning YAML line would mean a regression.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• js-yaml (tuned) 5.4.3
• yaml (eemeli) 2.9.0

Stringify time vs fastest, run over run — large-records

Lower is better, log scale. Each dumper's time as a multiple of the fastest in the same run (×) — machine-invariant. The fastest sits at 1× by construction; a rising Lightning YAML line would mean a regression.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• js-yaml (tuned) 5.4.3
• yaml (eemeli) 2.9.0

Full breakdown — every workload, avg ns per stringify() call (— marks a workload a library can’t represent):

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	js-yaml (tuned) 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	1.80 µs	5.59 µs	60.9 µs	47.3 µs	148 µs
medium-records	217 µs	628 µs	6.46 ms	5.34 ms	15.8 ms
large-records	2.91 ms	10.4 ms	95.5 ms	80.1 ms	204 ms
xlarge-records	24.8 ms	150 ms	886 ms	742 ms	1.88 s
medium-nested	471 µs	1.23 ms	9.98 ms	8.37 ms	24.3 ms
large-nested	3.49 ms	11.0 ms	89.1 ms	79.5 ms	201 ms
Plain block YAML
yaml-plain-small-records	1.41 µs	4.78 µs	45.4 µs	37.3 µs	117 µs
yaml-plain-medium-records	196 µs	615 µs	6.46 ms	4.88 ms	14.5 ms
yaml-plain-large-records	2.28 ms	8.27 ms	72.1 ms	62.3 ms	161 ms
yaml-plain-medium-nested	93.7 µs	268 µs	2.44 ms	2.13 ms	6.16 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	8.32 µs	56.4 µs	—	193 µs
yaml-rich-medium	—	735 µs	4.11 ms	—	16.5 ms
yaml-rich-large	—	8.37 ms	45.6 ms	—	186 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	js-yaml (tuned) 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	936 ns	5.69 µs	56.9 µs	42.4 µs	131 µs
medium-records	105 µs	606 µs	5.98 ms	4.54 ms	13.5 ms
large-records	2.20 ms	9.45 ms	79.6 ms	65.7 ms	177 ms
medium-nested	261 µs	1.16 ms	9.61 ms	8.22 ms	23.3 ms
large-nested	2.84 ms	12.1 ms	82.7 ms	70.1 ms	173 ms
Plain block YAML
yaml-plain-small-records	1.22 µs	4.94 µs	41.4 µs	32.5 µs	105 µs
yaml-plain-medium-records	157 µs	576 µs	5.67 ms	4.29 ms	13.0 ms
yaml-plain-large-records	2.51 ms	8.64 ms	67.9 ms	56.4 ms	147 ms
yaml-plain-medium-nested	57.8 µs	232 µs	2.25 ms	1.89 ms	5.60 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	8.02 µs	51.0 µs	—	171 µs
yaml-rich-medium	—	666 µs	4.05 ms	—	15.7 ms
yaml-rich-large	—	8.25 ms	45.4 ms	—	155 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	js-yaml (tuned) 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	802 ns	6.89 µs	382 µs	369 µs	183 µs
medium-records	104 µs	778 µs	43.0 ms	42.3 ms	20.9 ms
large-records	1.39 ms	12.9 ms	492 ms	466 ms	245 ms
medium-nested	184 µs	1.60 ms	70.9 ms	69.6 ms	52.6 ms
large-nested	1.65 ms	16.2 ms	515 ms	507 ms	392 ms
Plain block YAML
yaml-plain-small-records	656 ns	5.93 µs	300 µs	298 µs	140 µs
yaml-plain-medium-records	101 µs	740 µs	40.2 ms	38.8 ms	19.3 ms
yaml-plain-large-records	1.38 ms	16.6 ms	400 ms	389 ms	205 ms
yaml-plain-medium-nested	43.8 µs	347 µs	17.5 ms	16.9 ms	12.4 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	9.34 µs	477 µs	—	268 µs
yaml-rich-medium	—	753 µs	44.0 ms	—	23.1 ms
yaml-rich-large	—	13.8 ms	417 ms	—	236 ms

Stringify memory

Measured on AMD EPYC 9V45 96-Core Processor (unknown) · node 24.21.0 (x64-linux) · generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Peak memory by workload (stringify)

Lower is better. Whole-process peak resident set while dumping, in isolated child processes, fixed at 25 iterations. Each workload is scaled to its own heaviest dumper.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Peak memory, run over run — xlarge-records

Lower is better. Absolute peak resident set size (MB), one document per published run, oldest to newest.

• JSON
• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Full breakdown — every workload, peak RSS (MB):

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	80.2 MB	80.4 MB	79.2 MB	80.2 MB
medium-records	79.8 MB	90.8 MB	110 MB	149 MB
large-records	93.0 MB	214 MB	383 MB	401 MB
xlarge-records	252 MB	770 MB	986 MB	906 MB
medium-nested	82.0 MB	92.3 MB	148 MB	226 MB
large-nested	92.9 MB	209 MB	358 MB	387 MB
Plain block YAML
yaml-plain-small-records	79.8 MB	79.8 MB	79.5 MB	80.2 MB
yaml-plain-medium-records	102 MB	113 MB	114 MB	145 MB
yaml-plain-large-records	295 MB	286 MB	367 MB	395 MB
yaml-plain-medium-nested	92.5 MB	92.6 MB	109 MB	108 MB
Rich YAML (anchors + !!binary)
yaml-rich-small	—	80.0 MB	81.7 MB	81.9 MB
yaml-rich-medium	—	112 MB	113 MB	250 MB
yaml-rich-large	—	261 MB	336 MB	436 MB

Conformance

Pass rate across the official yaml-test-suite — the YAML 1.2 spec operationalized as executable cases — a property of the parser, not a per-workload measurement. Higher is better.

Generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

YAML test-suite conformance

Higher is better. Pass rate across 373 cases from the official yaml-test-suite.

Lightning YAML passes 98.4% of the suite — including all 91 negative (should-fail) cases; the per-library standing is in the chart above and the table below. Merge keys (<<) are absent from the test corpus and are currently read as ordinary keys; the suite also reports other remaining YAML 1.2 edge cases.

Conformance pass rate, run over run

Higher is better. Pass rate (%) per library, one document per published run, oldest to newest. The y-axis is zoomed to the labelled range where the parsers sit so run-to-run movement is visible.

• Lightning YAML
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0

Full breakdown — 373 cases, per library:

Library	Passed	Total	Score
Lightning YAML	367	373	98.4%
yaml (eemeli) 2.9.0	362	373	97.1%
js-yaml 5.4.3	354	373	94.9%

Bundle size

How many kilobytes each library adds to a browser bundle when an app imports only parse + stringify and ships it minified — a whole-library figure, not split by operation. Measured with js-yaml, yaml (eemeli), and lightning-yaml, tree-shaken and gzipped the same way a real app would ship them. Sizes are deterministic (not machine-dependent). Lower is better.

Generated 2026-10-16 · source 353832bfc94feada26c8e5c0fcc431b9e9b701b1

Bundle size (browser)

Lower is better. Minified + gzipped, the smallest result across 3 bundlers (vite, webpack, rolldown) for each library — parse + stringify only, tree-shaken.

Full breakdown — every bundler, gzip with the raw minified size alongside:

Bundler	Lightning YAML 0.1.1	js-yaml 5.4.3	yaml (eemeli) 2.9.0
vite	12.6 KB (41.8 KB min)	16.1 KB (55.0 KB min)	29.4 KB (96.5 KB min)
webpack	12.5 KB (41.6 KB min)	16.0 KB (54.4 KB min)	29.3 KB (96.3 KB min)
rolldown (rust)	12.1 KB (41.2 KB min)	16.4 KB (54.9 KB min)	29.1 KB (95.1 KB min)

Bundle size, run over run

Lower is better. Smallest gzip across bundlers (KB) per library, one document per published run, oldest to newest.

• Lightning YAML 0.1.1
• js-yaml 5.4.3
• yaml (eemeli) 2.9.0