fix(deps): float handlebars, form-data and tar to clear two criticals

[bsod90]

Lockfile-only, +24 / −37. Three descriptors already admitted the patched versions —
the lockfile was simply stale. I deleted only those blocks and re-resolved, so nothing
else moved.

package	descriptor	before	after	alert
handlebars	^4.7.7	4.7.7	4.7.9	closes #7891
form-data	^2.3.1, ^2.5.0	2.5.1	2.5.6	closes #7589
tar	^7.4.0, ^7.4.3, ^7.5.2	7.4.3, 7.5.2	7.5.22	partial

Two notes worth catching

form-data's 4.x copy is deliberately untouched. The advisory is < 2.5.4, so
4.0.5 was never affected. The already-open #11109 bumps 4.0.5 → 4.0.6 — the wrong
copy — and does not close #7589.

tar does not close, and I don't want to imply otherwise. Two vulnerable
resolutions remain, neither floatable:

tar@7.5.11   ← an EXACT pin from lerna@^9.0.7
tar@6.2.1    ← the ^6.x cluster, across a major boundary

This takes tar from five vulnerable resolutions to two. #8252 stays open pending
a lerna bump or an override.

Verification

• No version downgraded — removed 2.5.1 / 4.7.7 / 7.4.3 / 7.5.2; added 2.5.6 / 4.7.9, plus hasown@2.0.4 as a new transitive
• yarn install --frozen-lockfile succeeds — the consistency gate CI applies
• The three tar 7.x descriptors collapsed onto 7.5.22, a version already present and proven elsewhere in the tree

All three are patch/minor moves within ranges the packages already declare, so no
consumer sees an API change.

🤖 Generated with Claude Code

[claude]

Claude finished @bsod90's task in 1m 45s —— View job

---

Review: LGTM — lockfile changes check out. 0 blocking, 1 nit.

Full review

• Read the full diff
• Verify no downgrades / unintended moves
• Check remaining vulnerable resolutions
• Verify lockfile self-consistency
• Post review

What I verified

No downgrades, no collateral moves. Every version delta in the diff is upward: form-data 2.5.1 → 2.5.6, handlebars 4.7.7 → 4.7.9, tar 7.4.3 + 7.5.2 → 7.5.22. The rest of the diff is descriptor bookkeeping — combined-stream@^1.0.6, neo-async@^2.6.0, mime-types@^2.1.35, safe-buffer@^5.2.1, es-set-tostringtag@^2.1.0 moving between (or into) already-resolved blocks at unchanged versions. Nothing else re-resolved.

No dangling descriptors. I grepped for every descriptor removed from a block header to confirm nothing still depends on it:

removed descriptor	remaining consumers
combined-stream "^1.0.6"	none
neo-async "^2.6.0"	none

And the deps that the deleted tar 7.4.x/7.5.2 blocks uniquely pulled are not orphaned — mkdirp@^3.0.1 (yarn.lock:18122) is still referenced at :2773, minizlib@^3.0.1 (:18081) at :18020, :18031, :18872, :18900. So no unreachable-entry cruft either. All newly-referenced descriptors (es-set-tostringtag@^2.1.0 :12928, safe-buffer@^5.2.1 :21762, mime-types@^2.1.35 :17833) resolve to existing blocks.

tar claims confirmed. Post-change the lockfile has exactly three tar entries, and the two vulnerable ones are correctly characterized as non-floatable:

yarn.lock:23071  tar@7.5.11:                                  ← exact pin, not a range
yarn.lock:23082  tar@^6.0.2, ^6.1.11, ^6.1.2, ^6.2.1 → 6.2.1  ← major boundary
yarn.lock:23094  tar@^7.4.0, ^7.4.3, ^7.5.2, ^7.5.22 → 7.5.22 ← this PR

Five → two is accurate, and leaving #8252 open rather than claiming a close is the right call.

form-data 4.x correctly left alone. The 4.x block resolves to 4.0.5 (:14081), above the < 2.5.4 advisory range and above the 4.x fix line. Note that 4.x is the copy with direct dependents (packages/cubejs-cli, packages/cubejs-backend-cloud, both ^4.0.0); the 2.x copy this PR fixes is purely transitive, as is handlebars — neither has a direct dependent in any workspace package.json. That lowers the blast radius of this change to roughly zero, which is consistent with "no consumer sees an API change."

Install consistency — I did not run a full yarn install --frozen-lockfile here (multi-minute network install on a monorepo this size); CI's gate is the authoritative check. The static checks above are the part I could verify independently, and they're clean: every dependency edge touched by this diff has a resolving entry.

Findings

1 nit, posted inline: the new hasown@^2.0.4 block (yarn.lock:14854) leaves a second hasown copy alongside the existing 2.0.2 at :14847. 2.0.4 satisfies ^2.0.0/^2.0.2, so the three descriptors could collapse onto one entry. Cosmetic only.

Optional follow-up for #8252

The root package.json already has a resolutions block (package.json:68), so the tar@7.5.11 exact pin is reachable without waiting on a lerna release — Yarn 1 supports path-scoped resolutions, e.g. "lerna/**/tar": "^7.5.22", which pins the 7.x pin forward while leaving the ^6.x cluster untouched. Worth considering only if the advisory is actually reachable through lerna's usage; a dev-tooling-only path may not justify an override. Deliberately not doing that here — this PR's scope is the clean floats, and mixing an override into it would undercut the "nothing else moved" property.

· branch `maxim/oss-easy-crit-floats`

[claude]

Nit (dedupe): this creates a second hasown copy — the existing block at line 14847 (hasown@^2.0.0, hasown@^2.0.2) still resolves to 2.0.2, and ^2.0.4 doesn't fit that range so yarn split it out. Since 2.0.4 satisfies ^2.0.0 and ^2.0.2 too, deleting the old block and letting all three descriptors collapse onto 2.0.4 would keep one copy instead of two:

hasown@^2.0.0, hasown@^2.0.2, hasown@^2.0.4:
  version "2.0.4"

Purely cosmetic — no correctness impact, and not worth a re-resolve on its own if you'd rather keep the diff minimal.
true

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.35%. Comparing base (58f3cd7) to head (0623f5c).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11549   +/-   ##
=======================================
  Coverage   59.35%   59.35%           
=======================================
  Files         223      223           
  Lines       17989    17989           
  Branches     3641     3641           
=======================================
  Hits        10677    10677           
  Misses       6793     6793           
  Partials      519      519           

Flag	Coverage Δ
cube-backend	59.35% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.