chore(deps): refresh js-yaml to 3.15.1 and 4.3.1

[jasonworden]

Refreshes js-yaml in pnpm-lock.yaml, clearing the three remaining open Dependabot alerts. This empties the alert board.

Alerts cleared

Alert	Severity	Advisory	Vulnerable range
#56	High	GHSA-5p4m-2wfm-xmqj	>= 3.0.0, < 3.15.1
#19	High	GHSA-52cp-r559-cp3m	>= 4.0.0, < 4.3.0
#57	High	GHSA-5p4m-2wfm-xmqj	>= 4.0.0, < 4.3.1

Resolutions

Before	After	Clears
3.15.0	3.15.1	#56
4.2.0	4.3.1 (deduped)	#19, #57
4.3.1	4.3.1 (unchanged)	—
5.2.2	5.2.2 (unchanged)	—

Four resolved copies drop to three. 4.2.0 was the only vulnerable copy in the 4.x line — a 4.3.1 was already in the tree from @textlint/linter-formatter@15.8.0 (landed in #171), so the update simply merges the two and deletes 4.2.0's entries. 5.2.2 sits above every vulnerable range and is untouched. Net diff: 6 insertions, 14 deletions.

Why a lockfile refresh is the whole fix

Both parents' declared ranges already admitted the patched versions, so the lockfile was simply stale:

Vulnerable copy	Reached via	Parent declares	Admits patched?
js-yaml@3.15.0	@istanbuljs/load-nyc-config@1.1.0	^3.13.1	yes — 3.15.1
js-yaml@4.2.0	rc-config-loader@4.1.4	^4.1.1	yes — 4.3.1
js-yaml@4.2.0	@textlint/linter-formatter@15.7.1	^4.1.1	yes — 4.3.1

pnpm update js-yaml -r resolves all three. No manifest range bump is needed — js-yaml is not a direct dependency of any workspace package, so there is no declared floor of ours to raise.

Why not an overrides: entry

pnpm-workspace.yaml has no overrides: block (verified on 1c6af33), and adding one would change nothing. An override exists to force a resolution the declared ranges would otherwise forbid; here both ranges already permit the patched version and the lock now lands there on its own.

Worth noting because this dependency used to be the repo's standing example of a genuine tier-3 case: markdownlint-cli2 once hard-pinned js-yaml@4.1.0, which no range change could reach. That is no longer true — markdownlint-cli2@0.23.2 now resolves js-yaml@5.2.2, so the pin that justified an override is gone.

Exposure

Dev-only. Every path terminates in a devDependencies edge:

js-yaml@3.15.1
└─ @istanbuljs/load-nyc-config → babel-plugin-istanbul → jest@29.7.0
                                                       └ @mermaid-lint/jest@0.50.0 (devDependencies)

js-yaml@4.3.1
├─ @textlint/linter-formatter@15.7.1 → @secretlint/* → @vscode/vsce@3.9.2
│                                                    └ mermaid-lint-vscode@0.14.0 (devDependencies)
├─ @textlint/linter-formatter@15.8.0 → textlint@15.8.0  (peer — see below)
└─ rc-config-loader@4.1.4            → @textlint/config-loader, @secretlint/config-loader

js-yaml@5.2.2  (not vulnerable)
└─ markdownlint-cli2@0.23.2 → @mermaid-lint/markdownlint@0.50.0 (devDependencies)

GitHub labels these alerts scope: runtime, and pnpm why renders one path as @mermaid-lint/textlint@0.50.0 (dependencies) — neither means a consumer is exposed. @mermaid-lint/textlint declares exactly one real dependency, @mermaid-lint/core (workspace:*); textlint itself is a peerDependency (>=15.8.0). The whole textlint subtree is installed here only to satisfy that peer for local dev and tests. Downstream consumers supply their own textlint, and >=15.8.0 resolves to a version carrying @textlint/linter-formatter@15.8.0 → the already-patched js-yaml@4.3.1.

This is the lockfile-presence-≠-installed trap, so it was checked against packages/textlint/package.json rather than inferred from the lock. Nothing published reaches js-yaml.

No version bump

No packages/*/package.json is touched, so release.yml does not trigger. Consistent with #107, #174, #176, and #179.

Verification

• pnpm test — 54 files, 1231 tests passing
• pnpm lint — clean (145 files)
• pnpm --filter @mermaid-lint/jest test — 3 tests passing (jest's own tree is where js-yaml@3.x lives, so this is the directly affected suite)
• pnpm why js-yaml -r — 3 copies, all outside every vulnerable range
• Diff is pnpm-lock.yaml only, net −8 lines

🤖 Generated with Claude Code