chore(deps): unblock js-cookie 3.0.8 via react-use 17.6.1

[yumike]

Closes Dependabot alert #58 — GHSA-qjx8-664m-686j / CVE-2026-46625 (high): per-instance prototype hijack in assign() enabling cookie-attribute injection.

Why a lockfile bump alone couldn't fix it

The advisory affects js-cookie <= 3.0.5 and is patched only on the 3.x line. The 2.x line ended at 2.2.1 in 2019 — there is no patched 2.x. And the range capped below it:

@backstage/core-components (+ core-app-api, plugin-catalog-react, …)
→ react-use@17.6.0 → js-cookie: "^2.2.1" ← caps at <3.0.0
→ js-cookie 2.2.1

So yarn up -R js-cookie was a no-op: ^2.2.1 re-resolves to 2.2.1, already the highest 2.x. Same shape as the undici problem in #153, except the ceiling is a caret major boundary rather than an exact pin.

What this does

react-use@17.6.1 (2026-06-10) widened its range to js-cookie: ^3.0.0 — you were on 17.6.0, the last release that capped at 2.x, missing it by a single patch. Every consumer already declares react-use: ^17.2.4 / ^17.3.2, both of which accept 17.6.1, so one command reaches it:

yarn up -R react-use

Package	Before → After
react-use	17.6.0 → 17.6.1
js-cookie	2.2.1 → 3.0.8 ✅
@types/js-cookie	2.2.7 → 3.0.6

Lockfile-only: 13 insertions, 13 deletions, no manifest touched. react-use 17.6.1's other dependencies are unchanged.

Verification

js-cookie 2 → 3 is a genuine major (default path behaviour, noConflict removal, ESM-first build), so this got more scrutiny than an in-range re-resolution:

Check	Result
yarn install --immutable	✅ no drift
plugin-rw frontend tests, isolated	✅ 14 suites / 138 tests
yarn typecheck	✅ — would catch the @types/js-cookie major
yarn build	✅
yarn lint	✅
yarn test (full)	✅ 588 tests
yarn format:check	✅
yarn workspace app build	✅ — the ESM-first concern did not materialise

The bundle check

Checked whether js-cookie reaches the shipped app at all. It doesn't:

268 JS files in packages/app/dist/static/
14 contain "React" ← sanity check that the grep works
0 contain "document.cookie"

react-use's useCookie hook isn't reachable from our import graph, so webpack tree-shakes js-cookie away entirely. The vulnerable code was never present in the built app — not merely unexploitable, but absent.

Scope

@backstage/core-components is a peerDependency/devDependency of plugins/rw, so js-cookie never shipped inside the published package either; consumers resolve core-components from their own tree. The value here is a clean alerts page and a current transitive graph, not a closed hole.

🤖 Generated with Claude Code