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.18.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.18.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 7763 64-Core Processor (~3.09 GHz) · node 24.18.0 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

Measured in chromium 141.0.7390.37 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

Measured in webkit 26.0 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

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.2.1
• 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.2.1
• 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.2.1
• 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.2.1
• 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.2.1
• 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.2.1
• 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.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	4.76 µs	10.7 µs	44.6 µs	572 µs
medium-records	534 µs	1.00 ms	4.07 ms	62.3 ms
large-records	6.15 ms	11.5 ms	53.1 ms	654 ms
xlarge-records	60.5 ms	119 ms	559 ms	5.97 s
medium-nested	1.06 ms	1.79 ms	7.54 ms	93.9 ms
large-nested	7.72 ms	13.0 ms	60.3 ms	639 ms
Plain block YAML
yaml-plain-small-records	—	14.5 µs	56.4 µs	694 µs
yaml-plain-medium-records	—	1.65 ms	5.83 ms	82.7 ms
yaml-plain-large-records	—	16.4 ms	66.1 ms	755 ms
yaml-plain-medium-nested	—	852 µs	2.81 ms	30.6 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	22.8 µs	78.2 µs	922 µs
yaml-rich-medium	—	1.59 ms	5.18 ms	65.4 ms
yaml-rich-large	—	15.2 ms	53.1 ms	772 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	3.62 µs	12.1 µs	46.7 µs	372 µs
medium-records	394 µs	1.15 ms	3.78 ms	35.1 ms
large-records	4.60 ms	13.3 ms	46.8 ms	421 ms
medium-nested	748 µs	2.03 ms	6.70 ms	58.3 ms
large-nested	5.46 ms	14.7 ms	51.0 ms	414 ms
Plain block YAML
yaml-plain-small-records	—	16.9 µs	45.6 µs	398 µs
yaml-plain-medium-records	—	1.96 ms	5.27 ms	46.3 ms
yaml-plain-large-records	—	19.6 ms	60.5 ms	474 ms
yaml-plain-medium-nested	—	1.01 ms	2.51 ms	18.2 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	26.5 µs	68.6 µs	597 µs
yaml-rich-medium	—	1.93 ms	4.73 ms	38.3 ms
yaml-rich-large	—	18.4 ms	49.2 ms	548 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	3.25 µs	9.15 µs	36.9 µs	389 µs
medium-records	386 µs	812 µs	3.59 ms	34.7 ms
large-records	4.33 ms	9.42 ms	40.3 ms	465 ms
medium-nested	520 µs	1.48 ms	6.32 ms	63.3 ms
large-nested	3.81 ms	10.8 ms	46.0 ms	493 ms
Plain block YAML
yaml-plain-small-records	—	11.8 µs	44.0 µs	410 µs
yaml-plain-medium-records	—	1.37 ms	5.48 ms	46.9 ms
yaml-plain-large-records	—	13.7 ms	146 ms	591 ms
yaml-plain-medium-nested	—	725 µs	2.42 ms	18.8 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	20.3 µs	69.4 µs	643 µs
yaml-rich-medium	—	1.38 ms	5.07 ms	40.6 ms
yaml-rich-large	—	13.0 ms	49.7 ms	454 ms

Parse memory

Measured on AMD EPYC 7763 64-Core Processor (unknown) · node 24.18.0 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

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.2.1
• 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.2.1
• yaml (eemeli) 2.9.0

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

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	95.6 MB	77.9 MB	78.1 MB	80.6 MB
medium-records	78.4 MB	82.3 MB	97.1 MB	296 MB
large-records	97.9 MB	150 MB	377 MB	634 MB
xlarge-records	389 MB	535 MB	1106 MB	2676 MB
medium-nested	78.1 MB	80.4 MB	134 MB	318 MB
large-nested	99.6 MB	119 MB	359 MB	607 MB
Plain block YAML
yaml-plain-small-records	—	75.7 MB	77.2 MB	79.0 MB
yaml-plain-medium-records	—	81.8 MB	105 MB	290 MB
yaml-plain-large-records	—	122 MB	336 MB	569 MB
yaml-plain-medium-nested	—	81.0 MB	89.7 MB	153 MB
Rich YAML (anchors + !!binary)
yaml-rich-small	—	76.1 MB	79.3 MB	79.7 MB
yaml-rich-medium	—	83.6 MB	91.0 MB	231 MB
yaml-rich-large	—	111 MB	310 MB	482 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-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

Workload	Lightning YAML 0.1.1	js-yaml 5.2.1	yaml (eemeli) 2.9.0
Plain block YAML
yaml-plain-small-records	1.0×	1.0×	1.7×
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.2×
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-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

Workload	Lightning YAML 0.1.1	js-yaml 5.2.1	yaml (eemeli) 2.9.0
Plain block YAML
yaml-plain-small-records	1.0×	1.1×	7.4×
yaml-plain-medium-records	1.0×	2.2×	3.0×
yaml-plain-large-records	1.0×	2.8×	4.2×
Rich YAML (anchors + !!binary)
yaml-rich-small	1.0×	0.9×	3.2×
yaml-rich-medium	1.0×	1.4×	2.6×
yaml-rich-large	1.0×	1.9×	3.2×

Stringify (dump)

Serializing JavaScript values back to YAML text.

Stringify speed

Measured on AMD EPYC 7763 64-Core Processor (~3.09 GHz) · node 24.18.0 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

Measured in chromium 141.0.7390.37 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

Measured in webkit 26.0 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

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.2.1
• js-yaml (tuned) 5.2.1
• 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.2.1
• js-yaml (tuned) 5.2.1
• 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.2.1
• js-yaml (tuned) 5.2.1
• 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.2.1
• js-yaml (tuned) 5.2.1
• 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.2.1
• js-yaml (tuned) 5.2.1
• 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.2.1
• js-yaml (tuned) 5.2.1
• 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.2.1	js-yaml (tuned) 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	3.42 µs	10.0 µs	93.7 µs	59.6 µs	269 µs
medium-records	388 µs	1.04 ms	9.87 ms	6.44 ms	27.3 ms
large-records	4.99 ms	17.0 ms	143 ms	102 ms	323 ms
xlarge-records	41.6 ms	224 ms	1.31 s	953 ms	2.86 s
medium-nested	845 µs	1.89 ms	14.8 ms	11.1 ms	43.6 ms
large-nested	5.66 ms	17.2 ms	135 ms	103 ms	326 ms
Plain block YAML
yaml-plain-small-records	2.71 µs	8.60 µs	75.3 µs	47.5 µs	215 µs
yaml-plain-medium-records	358 µs	1.05 ms	9.01 ms	6.03 ms	25.2 ms
yaml-plain-large-records	4.50 ms	13.5 ms	114 ms	80.1 ms	261 ms
yaml-plain-medium-nested	163 µs	435 µs	3.68 ms	2.73 ms	10.9 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	14.8 µs	91.6 µs	—	380 µs
yaml-rich-medium	—	1.19 ms	6.48 ms	—	30.1 ms
yaml-rich-large	—	13.6 ms	77.6 ms	—	296 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.2.1	js-yaml (tuned) 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	1.76 µs	10.1 µs	90.4 µs	61.3 µs	248 µs
medium-records	199 µs	1.03 ms	9.26 ms	6.22 ms	23.6 ms
large-records	3.31 ms	14.8 ms	110 ms	78.4 ms	276 ms
medium-nested	458 µs	1.83 ms	13.8 ms	10.2 ms	36.9 ms
large-nested	3.77 ms	15.3 ms	106 ms	82.5 ms	279 ms
Plain block YAML
yaml-plain-small-records	2.31 µs	8.56 µs	76.7 µs	49.6 µs	180 µs
yaml-plain-medium-records	301 µs	999 µs	8.51 ms	5.84 ms	22.2 ms
yaml-plain-large-records	3.73 ms	11.7 ms	89.1 ms	63.5 ms	225 ms
yaml-plain-medium-nested	124 µs	405 µs	3.59 ms	2.54 ms	9.28 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	14.8 µs	86.5 µs	—	325 µs
yaml-rich-medium	—	1.13 ms	6.11 ms	—	25.4 ms
yaml-rich-large	—	12.2 ms	64.1 ms	—	256 ms

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.2.1	js-yaml (tuned) 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	1.39 µs	10.1 µs	107 µs	67.7 µs	300 µs
medium-records	184 µs	1.18 ms	11.3 ms	7.06 ms	28.8 ms
large-records	2.11 ms	20.2 ms	147 ms	99.1 ms	349 ms
medium-nested	335 µs	2.39 ms	19.6 ms	13.3 ms	75.0 ms
large-nested	2.40 ms	24.2 ms	147 ms	111 ms	547 ms
Plain block YAML
yaml-plain-small-records	1.13 µs	8.84 µs	82.8 µs	54.1 µs	231 µs
yaml-plain-medium-records	200 µs	1.22 ms	11.0 ms	7.17 ms	28.1 ms
yaml-plain-large-records	2.11 ms	20.0 ms	123 ms	84.6 ms	291 ms
yaml-plain-medium-nested	85.3 µs	591 µs	4.26 ms	3.04 ms	18.7 ms
Rich YAML (anchors + !!binary)
yaml-rich-small	—	15.1 µs	106 µs	—	457 µs
yaml-rich-medium	—	1.18 ms	7.79 ms	—	34.9 ms
yaml-rich-large	—	13.0 ms	82.1 ms	—	342 ms

Stringify memory

Measured on AMD EPYC 7763 64-Core Processor (unknown) · node 24.18.0 (x64-linux) · generated 2026-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

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.2.1
• 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.2.1
• yaml (eemeli) 2.9.0

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

Workload	JSON	Lightning YAML 0.1.1	js-yaml 5.2.1	yaml (eemeli) 2.9.0
JSON-shaped (records & nested)
small-records	77.6 MB	78.2 MB	77.9 MB	77.2 MB
medium-records	78.9 MB	86.9 MB	107 MB	145 MB
large-records	92.1 MB	227 MB	377 MB	403 MB
xlarge-records	249 MB	750 MB	1224 MB	933 MB
medium-nested	82.2 MB	91.3 MB	193 MB	211 MB
large-nested	90.7 MB	214 MB	421 MB	377 MB
Plain block YAML
yaml-plain-small-records	76.6 MB	77.6 MB	79.4 MB	77.5 MB
yaml-plain-medium-records	99.0 MB	106 MB	111 MB	188 MB
yaml-plain-large-records	291 MB	280 MB	395 MB	403 MB
yaml-plain-medium-nested	89.2 MB	90.6 MB	91.3 MB	107 MB
Rich YAML (anchors + !!binary)
yaml-rich-small	—	77.5 MB	79.4 MB	79.4 MB
yaml-rich-medium	—	109 MB	108 MB	247 MB
yaml-rich-large	—	255 MB	292 MB	423 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-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

YAML test-suite conformance

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

Lightning YAML passes 97.6% 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 (<<), absent from the test corpus, are the only unimplemented construct.

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.2.1
• yaml (eemeli) 2.9.0

Full breakdown — 373 cases, per library:

Library	Passed	Total	Score
Lightning YAML	364	373	97.6%
yaml (eemeli) 2.9.0	362	373	97.1%
js-yaml 5.2.1	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-08-10 · source eaf00b1ed7702e4cfa9fff566fbc7f88e989a423

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.2.1	yaml (eemeli) 2.9.0
vite	12.5 KB (41.4 KB min)	15.5 KB (52.1 KB min)	29.4 KB (96.5 KB min)
webpack	12.4 KB (41.0 KB min)	15.5 KB (51.8 KB min)	29.3 KB (96.3 KB min)
rolldown (rust)	12.0 KB (40.8 KB min)	15.6 KB (51.2 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.2.1
• yaml (eemeli) 2.9.0