chore(deps): pin js-yaml and tar via pnpm overrides

[jakehobbs]

What

Adds pnpm overrides so transitive resolutions of js-yaml and tar land on current releases instead of the older versions the lockfile had pinned:

Package	Before	After
js-yaml (3.x line)	3.14.2	3.15.0
js-yaml (4.x line)	4.2.0	4.3.0
tar	6.2.1 + 7.2.0	7.5.21

"overrides": {
  "js-yaml@<3.15.0": "3.15.0",
  "js-yaml@>=4 <4.3.0": "4.3.0",
  "tar@<7.5.18": "7.5.21"
}

All three are dev-only, transitive dependencies. Range-based selectors are used (not exact pins) so any future sub-dependency that resolves into the old range is caught too.

Why overrides instead of bumping the parent packages

I looked at bumping the packages that pull these in rather than using overrides, and overrides are the cleaner lever here:

• js-yaml — the target versions (3.15.0, 4.3.0) are published under the v3-legacy / v4-legacy dist-tags (latest is on a newer major line the parents don't track). The parents (front-matter, @yarnpkg/parsers) stay within ^3 / ^4, and these are the highest versions in those ranges, so the override just makes that resolution explicit and regression-proof.
• tar — the 6.2.1 copies come from lerna's tooling (node-gyp, cacache, pacote), which are transitive and can't be bumped directly. The only direct handle is lerna, and moving it forward is a major bump that touches the release workflow — more risk and churn than warranted here.
• prool pins tar to exactly 7.2.0, even on its latest release, so no upstream bump reaches that copy at all. The tar override is the only single change that covers every path, including this one.

Verification

• pnpm install completes cleanly on Node 22.20.0 (per .nvmrc), including the halp build + husky postinstall steps — the tar 6 → 7 major bump does not break the dependency tree.
• Confirmed no remaining js-yaml < 3.15.0, js-yaml 4.0–4.2, or tar < 7.5.18 entries in pnpm-lock.yaml.

🤖 Generated with Claude Code

---

PR-Codex overview

This PR focuses on updating dependencies in the package.json and pnpm-lock.yaml files, particularly the version of js-yaml and tar, along with adjusting their specifications.

Detailed summary

• Updated js-yaml from 4.2.0 to 4.3.0.
• Added js-yaml@<3.15.0 with version 3.15.0.
• Added js-yaml@>=4 <4.3.0 with version 4.3.0.
• Added tar@<7.5.18 with version 7.5.21.
• Updated relevant js-yaml references in pnpm-lock.yaml.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[Copilot]

Pull request overview

This PR updates the workspace’s pnpm dependency resolution behavior so transitive installs of js-yaml and tar are forced onto newer patched versions via pnpm.overrides, and refreshes the lockfile accordingly.

Changes:

• Add range-based pnpm.overrides entries to force js-yaml (3.15.0 / 4.3.0) and tar (7.5.21).
• Update pnpm-lock.yaml to reflect the new override rules and resolved versions, removing older tar/js-yaml entries.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
package.json	Adds pnpm.overrides rules to force patched js-yaml and tar transitive resolutions.
pnpm-lock.yaml	Updates overrides + resolved dependency graph to match the new forced versions.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[jakehobbs]

Good catch — fixed in 546e3f2. Root cause was that js-yaml is a direct devDependency declared as ^4.2.0, and the js-yaml@>=4 <4.3.0 override matched it and rewrote the importer's specifier to 4.3.0, creating the mismatch you flagged.

Rather than keep the override fighting the declared range, I bumped the direct devDependency to ^4.3.0 so package.json and the lockfile specifier agree (specifier: ^4.3.0, version: 4.3.0). The >=4 <4.3.0 override is retained only to catch transitive consumers that request the older range (e.g. js-yaml@~4.1.0 via eslint/lerna/cosmiconfig), which no longer overlaps the direct dependency.

Verified pnpm install --frozen-lockfile now succeeds.