chore(deps): consolidate Dependabot updates

[lv10]

Consolidates 15 of the 22 open Dependabot PRs into a single change: everything that is a
lockfile-level security/patch update, plus the slides toolchain. Bumps were re-derived
(npm update per project, lockfiles regenerated) rather than merged, so no lockfile
conflicts.

The Expo SDK and React Native majors are not in here — see "Left for follow-up" below.

slides — superseded PRs #78, #89, #73, #76, #83, #80

Package	From	To	Bump	Supersedes	Status
@slidev/cli	0.49.10	0.49.29	patch	#78	✅
@nuxt/kit (transitive)	3.12.1	3.21.11	minor	#89	✅
mdast-util-to-hast (transitive)	13.2.0	13.2.1	patch	#76	✅
lodash-es (transitive)	4.17.21	4.18.1	minor	#83	✅
js-yaml (transitive)	3.14.1 → 3.15.1, 4.1.0 → 4.3.1		minor	#73	✅
diff (transitive)	5.2.0	dropped from the tree	—	#78, #80	✅
tar (transitive)	6.2.1	dropped from the tree	—	#89	✅

diff and tar are no longer in slides' dependency tree at all after the @slidev/cli
0.49.29 resolution, which resolves those advisories outright.

npm audit in slides: 43 advisories (2 critical / 18 high / 20 moderate / 3 low) on
main → 21 (0 critical / 3 high / 17 moderate / 1 low) on this branch. Both criticals
cleared.

Verified with the exact command CI runs: npm ci then
npm run slides:build -- --base /react-native-workshop/ — both pass, same as on main.

CI Node version bumped to 20

.github/workflows/deploy.yml moves from node-version: 18 to 20. The refreshed slides
tree pulls in marked@16.4.2, which declares engines.node: ">= 20" and arrives as a
non-optional runtime dependency of mermaid (this PR moves mermaid 10.9.1 → 11.16.1,
and mermaid declares marked: ^16.3.0). On main the slides tree contained no marked
at all and every engines.node constraint in it was Node 18 compatible, so this is
introduced here.

On Node 18.20.8 npm ci warns EBADENGINE ... marked@16.4.2 required: { node: '>= 20' }
and the build still succeeds only because slides.md contains no mermaid diagrams, so the
Node 20 code path is never reached. That is luck, not design. On Node 20.20.2, npm ci
emits zero EBADENGINE warnings and npm run slides:build -- --base /react-native-workshop/ builds successfully (✓ built in 3.00s).

step0–step5 — superseded PRs #84, #87, #85, #86, #74, #77, #68, #69, #75, #73

Transitive security updates, applied consistently across all six step projects so they
don't drift apart:

Package	From	To	Supersedes
lodash	4.17.21	4.18.1	#84 (step0), #87 (step1), #85 (step2), #86 (step4)
body-parser	1.20.2	1.20.6	#74 (step1), #77 (step2)
qs	6.11.0	6.15.3	#77 (step2)
ws	6.2.2 → 6.2.6, 7.5.9 → 7.5.13, 8.14.2 → 8.21.3		#68 (step1)
fast-xml-parser	4.3.2	4.5.7	#69 (step3)
node-forge	1.3.1	1.4.0	#75 (step3)
js-yaml	3.14.1 → 3.15.1, 4.1.0 → 4.3.1		#73

On ws, #68 asked for 8.17.1 on all three major lines, but the 6.x and 7.x copies are
pinned by their parents' ranges. Each line moved to its patched release instead — 6.2.6,
7.5.13 and 8.21.3 — all of which are at or above the fix for the ws DoS advisory
(6.2.3 / 7.5.10 / 8.17.1), so the vulnerability is closed on every line.

js-yaml is now patched in the step projects as well as in slides, so the two really do
stay in step. Both copies were already inside their consumers' declared ranges (^3.13.1
for @expo/cli / @expo/package-manager / cosmiconfig, ^4.1.0 for @expo/xcpretty),
so npm update js-yaml --package-lock-only was enough: package.json is byte-identical in
all six projects and each lockfile diff touches only the js-yaml entries — nothing else
moved. This clears GHSA-52cp-r559-cp3m and GHSA-5p4m-2wfm-xmqj from every step audit:

Project	npm audit before	after
step0	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step1	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step2	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step3	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step4	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step5	55 (3 crit / 27 high)	54 (3 crit / 26 high)

Verified: npm ci resolves cleanly in all seven projects (slides, step0–step5).
These step projects define no build or test script (only android/ios/start/web), so
lockfile resolution is the available signal.

A blanket npm update --package-lock-only on the steps was deliberately not done. It
would take step2 from 56 advisories to 35, but it moves 228 packages including the entire
babel and metro toolchain of an Expo 49 / React Native 0.72 app, and there is no build or
test in these projects to prove that safe.

Left for follow-up — 7 PRs stay open

PR	Bump	Why it isn't here
#72, #71	react-native 0.72.6 → 0.82.1 (step1, step2)	Full React Native major upgrade
#90, #82, #91, #92, #88	expo 49.0.16 → 54.0.32, tar 6 → 7 (step1–step5)	Expo SDK 49 → 54 is five SDK generations

Moving these six workshop apps from Expo SDK 49 to 54 is a real migration, not a lockfile
change: it drags react 18 → 19, @types/react, react-native-reanimated,
react-native-safe-area-context and the babel config with it, and the workshop's own step
content would need to be re-verified against the new SDK on a device or simulator. There is
no build or test in these projects to prove such a change is safe, so it is deliberately
left to a maintainer who can run the workshop end to end.

The tar 6 → 7 halves of those PRs are majors capped by their parents' ranges.
To be explicit: tar 6.2.1 does not carry the fix, and deferring it leaves real
advisories open. npm audit against the step lockfiles in this PR reports tar 6.2.1 as
critical, matched by twelve advisories whose ranges include 6.2.1 — among them
GHSA-23hp-3jrh-7fpw (critical, decompression/parse DoS, <=7.5.18),
GHSA-34x7-hfp2-rc4v (high, hardlink path traversal, <7.5.7) and GHSA-83g3-92jg-28cx
(high, hardlink target escape, <7.5.8). npm reports the fix as
{"name":"expo","version":"57.0.14","isSemVerMajor":true}, i.e. it requires an Expo major,
which is why it is deferred rather than because the exposure is closed. This is pre-existing
exposure on main, not something this PR introduces.

[SociableSteve]

The lockfiles themselves are sound. I verified every notable bump against registry.npmjs.org (integrity hashes in the lockfiles match the published tarballs exactly for @slidev/cli 0.49.29, mermaid 11.16.1, lodash 4.18.1, lodash-es 4.18.1, ws 6.2.6/7.5.13/8.21.3, qs 6.15.3, node-forge 1.4.0, body-parser 1.20.6, fast-xml-parser 4.5.7, @nuxt/kit 3.21.11). npm ci resolves cleanly in all seven projects, the diff is genuinely lockfile-only (no package.json, no source), and the slides build on Node 18 produces an index.html identical to main's apart from asset hashes. The slides advisory count really does go 43 to 21 with both criticals cleared, and diff and tar really are gone from the slides tree. Good, well-scoped work.

Three things to fix before merge, two of them small.

1. js-yaml was patched in slides but left behind in all six step projects, which contradicts the PR's own "applied consistently across all six step projects so they don't drift apart". It is a two-line, in-range fix and npm reports fixAvailable: true (no major involved).

2. The description's justification for deferring the tar bumps is factually wrong. npm audit against this PR's own step lockfiles reports tar 6.2.1 as critical. Deferring is still the right call, the sentence just needs to say so honestly rather than claiming the exposure is closed.

3. The refreshed slides tree now contains a package that does not support the Node 18 pinned in deploy.yml. Not breaking today, but the deploy job is one patch bump away from it.

For the record, I checked whether a blanket npm update --package-lock-only on the steps would be a cheap win. It does take step2 from 56 advisories to 35, but it moves 228 packages including the entire babel and metro toolchain of an Expo 49 / React Native 0.72 app with no build or test to prove it safe. Leaving that out was the right judgement, so I am not asking for it. The js-yaml item below is different: it is two lines and touches nothing else.

[SociableSteve]

js-yaml was patched in slides but not in any of the six step projects.

This PR moves js-yaml to 3.15.1 / 4.3.1 in slides, but step0 through step5 all stay on 3.14.1 (node_modules/js-yaml) and 4.1.0 (node_modules/@expo/xcpretty/node_modules/js-yaml). That directly contradicts the description's "applied consistently across all six step projects so they don't drift apart": slides and steps now carry different js-yaml.

Both are in range already, so no package.json change is needed. The consumers declare ^3.13.1 (@expo/cli, @expo/package-manager, cosmiconfig) and ^4.1.0 (@expo/xcpretty). I ran npm update js-yaml --package-lock-only against this PR's own step2 lockfile and it touches exactly two entries and nothing else:

node_modules/@expo/xcpretty/node_modules/js-yaml: 4.1.0 -> 4.3.1
node_modules/js-yaml: 3.14.1 -> 3.15.1

package.json is byte-identical afterwards, and npm audit confirms fixAvailable: true (not a semver-major). As merged, npm audit still reports js-yaml at high in every step project, matching GHSA-52cp-r559-cp3m (>=3.0.0 <3.15.0, >=4.0.0 <4.3.0) and GHSA-5p4m-2wfm-xmqj (>=3.0.0 <3.15.1, >=4.0.0 <4.3.1). Applying the two-line update clears the js-yaml entry from the audit outright and takes step2 from 56 advisories to 55 (high 28 to 27).

Worth doing in all six steps so the projects stay in step with slides, as the description says they do.

[lv10]

Fixed in acf4363. Ran npm update js-yaml --package-lock-only in all six step projects. package.json is byte-identical in every one of them (diffed before/after), and the combined diff across the six lockfiles is 204 changed lines of which every single one is a js-yaml version / resolved / integrity / license / funding field — the only resolved URLs anywhere in the diff are js-yaml-3.14.1 -> 3.15.1 and js-yaml-4.1.0 -> 4.3.1. Nothing else moved.

Audit delta, measured per project against this PR's pre-change lockfile:

Project	before	after
step0	56 (3 crit / 28 high / 19 mod / 6 low)	55 (3 crit / 27 high / 19 mod / 6 low)
step1	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step2	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step3	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step4	56 (3 crit / 28 high)	55 (3 crit / 27 high)
step5	55 (3 crit / 27 high)	54 (3 crit / 26 high)

step2 matches your 56 -> 55 / high 28 -> 27 exactly. step5 starts one lower than the rest, so it lands at 54. The js-yaml key is gone from npm audit --json output entirely in all six, not just downgraded in severity.

npm ci --dry-run resolves in all six (1223-1234 packages each), and a real npm ci in step2 puts 3.15.1 at node_modules/js-yaml and 4.3.1 at node_modules/@expo/xcpretty/node_modules/js-yaml on disk.

The blanket npm update --package-lock-only on the steps is not included, per your note. I added a paragraph to the description recording that it was considered and why it was left out, so the next reader does not have to rediscover the 228-package figure.

[SociableSteve]

The refreshed slides tree now pulls in packages that do not support the Node 18 pinned in CI.

.github/workflows/deploy.yml:18 pins node-version: 18, and lines 19 to 22 run npm ci and npm run slides:build from this directory. This PR introduces marked@16.4.2 with engines.node: ">= 20". It arrives as a non-optional runtime dependency of mermaid, which this PR moves from 10.9.1 to 11.16.1 (mermaid declares marked: ^16.3.0). On main the slides tree had no marked at all, and every engines constraint in it was Node 18 compatible, so this is introduced here rather than pre-existing.

Two more arrive alongside it: c12's nested chokidar@5.0.0 and readdirp@5.1.1 both declare >= 20.19.0.

I ran the exact CI commands on Node 18.20.8 and they still pass, so nothing is broken today:

npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: 'marked@16.4.2',
npm warn EBADENGINE   required: { node: '>= 20' },
npm warn EBADENGINE   current: { node: 'v18.20.8', npm: '10.8.2' }
npm warn EBADENGINE }
...
✓ built in 2.86s

It survives because slides.md uses no mermaid diagrams, so the Node 20 code path is never reached. That is luck rather than design: the deploy job is one patch bump away from a hard failure, and npm ci is already warning. Since the toolchain is being moved anyway, bumping deploy.yml to node-version: 20 in this PR is the cheap fix.

[lv10]

Bumped deploy.yml to node-version: 20 in acf4363.

Confirmed the diagnosis before changing it. marked@16.4.2 is in this branch's slides lockfile with engines.node: ">= 20", dev: false / optional: false, and mermaid 11.16.1 declares it as a plain dependencies entry at ^16.3.0. On main's slides lockfile there is no marked entry at all, and the only engines.node constraints mentioning 20 are vite, @vitejs/plugin-vue and vite-plugin-static-copy, all of which read ^18.0.0 || >=20.0.0 — so Node 18 was genuinely satisfied everywhere on main and this is introduced here. slides.md contains zero mermaid occurrences, which is why the Node 20 path is never reached.

Reproduced your Node 18 run, then verified the fix:

# Node 18.20.8
$ npm ci
npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: 'marked@16.4.2',
npm warn EBADENGINE   required: { node: '>= 20' },
npm warn EBADENGINE   current: { node: 'v18.20.8', npm: '10.8.2' }
npm warn EBADENGINE }
added 661 packages, and audited 662 packages in 5s

# Node 20.20.2
$ npm ci
added 684 packages, and audited 685 packages in 4s
EBADENGINE count: 0
$ npm run slides:build -- --base /react-native-workshop/
✓ built in 3.00s

Zero EBADENGINE on 20 and the CI build command succeeds.

One correction to the secondary part of the finding: c12's nested chokidar@5.0.0 and readdirp@5.1.1 do declare >= 20.19.0, but the whole c12 subtree is marked optional: true in the lockfile, so npm ci on Node 18 skipped it — node_modules/c12 does not exist after the Node 18 install, and only marked warned. They install on Node 20 (hence 661 -> 684 packages), which is part of why 20 is the right pin, but on Node 18 they were never the live problem. marked was, since it is non-optional.

[SociableSteve]

Description correction (no code change needed here): the "Left for follow-up" table's claim about tar is not correct.

The body says "tar 6.2.1 already carries the fix for its advisory, so nothing is left exposed by deferring them." Running npm audit against this PR's own step lockfiles reports tar at 6.2.1 as critical, not clean. It is matched by twelve advisories whose ranges include 6.2.1, among them:

• GHSA-23hp-3jrh-7fpw, critical, "Decompression/parse DoS via unlimited input", range <=7.5.18
• GHSA-34x7-hfp2-rc4v, high, "Arbitrary File Creation/Overwrite via Hardlink Path Traversal", range <7.5.7
• GHSA-83g3-92jg-28cx, high, "Arbitrary File Read/Write via Hardlink Target Escape", range <7.5.8

npm reports fixAvailable: {"name": "expo", "version": "57.0.14", "isSemVerMajor": true}, which confirms the rest of your reasoning: the fix genuinely requires an Expo major, so deferring is the right call. This is pre-existing exposure and not something the PR introduces. It is only the justifying sentence that needs correcting, so a reader does not come away believing the tar advisories are closed when they are still open.

[lv10]

Corrected in the description. Verified the claim first — npm audit --json against this PR's step2 lockfile reports:

tar severity: critical
tar fixAvailable: {"name":"expo","version":"57.0.14","isSemVerMajor":true}

So the old sentence was wrong on both halves: 6.2.1 does not carry the fix, and deferring does leave advisories open. The "Left for follow-up" section now says so explicitly, names GHSA-23hp-3jrh-7fpw (critical, <=7.5.18), GHSA-34x7-hfp2-rc4v (high, <7.5.7) and GHSA-83g3-92jg-28cx (high, <7.5.8), and states that the reason for deferring is the Expo semver-major requirement rather than the exposure being closed. It also notes this is pre-existing on main and not introduced here.

No code change — the tar bumps stay deferred, which your fixAvailable output confirms is correct.

[lv10]

All three items addressed in acf4363, each answered inline with the evidence. Summary:

1. js-yaml in the step projects. npm update js-yaml --package-lock-only in all six. package.json byte-identical in every one, and across the six lockfiles all 204 changed lines are js-yaml fields — the only resolved URLs in the whole diff are js-yaml-3.14.1 → 3.15.1 and js-yaml-4.1.0 → 4.3.1. Audit per project: step0–step4 56 → 55 (high 28 → 27), step5 55 → 54 (high 27 → 26), and the js-yaml key disappears from npm audit --json in all six. step2 matches your measurement exactly. npm ci --dry-run resolves in all six; a real npm ci in step2 confirms 3.15.1 and 4.3.1 on disk.

2. The tar sentence. Corrected. I verified it before rewriting: npm audit --json on the step2 lockfile reports tar critical with fixAvailable: {"name":"expo","version":"57.0.14","isSemVerMajor":true}. The description now states plainly that 6.2.1 does not carry the fix and that deferring leaves the advisories open, names GHSA-23hp-3jrh-7fpw / GHSA-34x7-hfp2-rc4v / GHSA-83g3-92jg-28cx, and gives the Expo semver-major requirement as the actual reason for deferring.

3. Node 18 in deploy.yml. Bumped to node-version: 20. On Node 18.20.8 I reproduced your EBADENGINE warning for marked@16.4.2; on Node 20.20.2 npm ci emits zero EBADENGINE warnings and npm run slides:build -- --base /react-native-workshop/ builds (✓ built in 3.00s). One correction on the secondary part: c12's nested chokidar@5.0.0 / readdirp@5.1.1 are marked optional: true in the lockfile, so npm ci on Node 18 skipped the whole c12 subtree and only marked actually warned. They do install on Node 20 (661 → 684 packages), so the pin is still right, but marked was the live problem.

I also recorded in the description that the blanket npm update --package-lock-only on the steps was considered and deliberately left out, with your 228-package / Expo 49 reasoning, so the next reader does not have to rediscover it. And I added the measured slides audit delta — 43 (2 critical / 18 high / 20 moderate / 3 low) → 21 (0 critical / 3 high / 17 moderate / 1 low) — since the body previously asserted the improvement without the numbers.

[SociableSteve]

All three items from the previous round are addressed at acf4363, verified against the head rather than taken on trust.

1. js-yaml in the steps. node_modules/js-yaml is 3.15.1 and node_modules/@expo/xcpretty/node_modules/js-yaml is 4.3.1 in all six step lockfiles. Base to head, each step lockfile changes exactly 20 entries: lodash 4.17.21 to 4.18.1, body-parser 1.20.2 to 1.20.6, qs 6.11.0 to 6.15.3, fast-xml-parser 4.3.2 to 4.5.7, node-forge 1.3.1 to 1.4.0, the two js-yaml copies, and the five ws copies (6.2.2 to 6.2.6, four at 7.5.9 to 7.5.13, 8.14.2 to 8.21.3). No downgrades, no major bumps, and packages[""] is unchanged in all seven projects, so no package.json moved. npm audit --package-lock-only: step2 55 (3 critical / 27 high), step5 54 (3 critical / 26 high), js-yaml gone from the advisory list in both. Matches the description's table.

2. The tar sentence. The corrected text is accurate. npm audit --json on the step2 and step5 lockfiles reports tar as critical with fixAvailable: {"name":"expo","version":"57.0.14","isSemVerMajor":true}, which is what the description now says.

3. Node 20 in deploy.yml. Confirmed on Node 20.20.2: npm ci in slides adds 684 packages with zero EBADENGINE warnings, and npm run slides:build -- --base /react-native-workshop/ succeeds. Your correction on c12 is right: chokidar@5.0.0 and readdirp@5.1.1 are optional: true in the lockfile, and marked@16.4.2 was the only non-optional Node 20 constraint.

Also checked: slides npm audit on the installed tree is 21 (0 critical / 3 high / 17 moderate / 1 low), exactly as stated, and diff and tar have no entries at all in the slides lockfile. The one apparent downgrade in slides, get-stream 8.0.1 to 6.0.1, is re-hoisting rather than a regression: execa@8 is gone from the tree and the two remaining consumers (got, cacheable-request) both declare ^6.0.1.

Two optional, non-blocking notes:

• node-version: 20 works today, but it passes partly because the floating 20 tag resolves to 20.19 or later, which c12's nested chokidar@5.0.0 / readdirp@5.1.1 (node: ">= 20.19.0") require. Node 20 is also past end of support. node-version: 22 satisfies every engines.node in the refreshed tree with room to spare. Not a blocker: those two are optional and are skipped or satisfied either way.
• The slides table lists the bumps the superseded Dependabot PRs asked for, so the transitive majors that came with the @slidev/cli 0.49.29 resolution (mermaid 10 to 11, @vueuse/core 10 to 11, uuid 9 to 14, dotenv 16 to 17) are not visible there. mermaid is named later in the body, so nothing is misstated, but a line noting that the refresh carries transitive majors would save the next reader the diff.

Worth noting for whoever merges: deploy.yml runs only on push to main, so nothing in CI exercises npm ci or the slides build on this PR. The Node bump and the slides refresh rest on local runs, mine included.