fix(frontend): restore the 33 @dicebear entries missing from package-lock

[lilyshen0722]

npm ci exits 1 on frontend/ at origin/main today, with 33 Missing: entries — both declared dependencies (@dicebear/core, @dicebear/collection) plus the 31 style packages collection re-exports. So no fresh checkout can install or reproducibly lint the frontend.

Repair is one command, not a hand-edit:

npm install --package-lock-only @dicebear/core@9.4.3 @dicebear/collection@9.4.3

npm resolves the fan-out. This is @sprint-review's measurement on TASK-084; I re-derived every number independently before shipping it rather than carrying it forward, and all five agree.

Review this as parsed JSON, never as a patch

The semantic change is 33 entries. The textual diff is ~32.8k lines (16,631 insertions / 16,200 deletions) because npm rewrites ordering across the whole file — which is exactly the shape unrelated drift would hide in unnoticed. Four numbers are the review:

check	result
packages	1183 → 1216 — 33 added, 0 removed
version changes	exactly one: root entry frontend 1.0.0 → 1.1.0
lockfileVersion	3 → 3, no legacy dependencies block introduced
eslint pins	byte-identical — eslint 8.57.1, eslint-plugin-i18next 6.1.5, eslint-plugin-react 7.37.5, eslint-plugin-react-hooks 4.6.2, eslint-config-react-app 7.0.1; zero eslint packages among the 33 added

The root version bump is not drift: frontend/package.json already says 1.1.0, so the committed lock was stale on its own root version, and was also missing the license field. The repair corrects both.

Verified end to end, not by dry-run

On a clean detached worktree at ccacf0235:

1. npm ci --dry-run → exit 1, 33 Missing: (reproduced the break)
2. apply the repair → npm ci --dry-run → exit 0, 0 Missing:
3. a real npm ci → succeeds, 24s (not just the dry-run)
4. npx eslint src --ext .js,.jsx,.ts,.tsx on that freshly installed tree → 17 errors / 160 warnings, 6 files, split i18next/no-literal-string 14 · react/display-name 2 · react/no-unescaped-entities 1

Step 4 is the one that mattered to me: the 17/160 figure had only ever been measured in an already-installed local tree, and a reproducibility objection against it was the one open half. A from-scratch install off the repaired lock reproduces it to the file and the rule. The number does not depend on anyone's drifted node_modules.

The 33 are exactly the dicebear fan-out — nothing else wants them

Reverse-indexed every dependencies / peerDependencies / optionalDependencies / devDependencies field across all 1216 packages in the repaired lock. Of the 33 added names, the only one with a depender outside {root, @dicebear/collection} is @dicebear/core, required by its own 31 style siblings. So the repair scope is closed under the two declared deps; no unrelated package in the tree pulls any of them in independently, and removing a dicebear dep later would take the whole subtree with it cleanly.

Why this is not blocked behind #1324

TASK-084 bundles this with the backend .ts lint burn-down, whose blocker is real — that config needs @typescript-eslint/parser@^8, which arrives with #1324. That blocker does not reach here: #1324 touches zero frontend files, and across all 100 open PRs none touches frontend/package-lock.json or frontend/package.json. Either press order is safe and there is nothing to sequence.

Not verified

I did not run the frontend test suite on the repaired tree — the change is lock-only and the eslint pins are byte-identical, but that is an argument, not a measurement. I also have not checked whether the root 1.1.0 sync has any consequence beyond the lock.

Refs TASK-084.

🤖 Generated with Claude Code

[lilyshen0722]

Reviewed as parsed JSON, per your own instruction. Clean — approving on CI. At 66a237f2, one file, one Lily-authored commit, base main, 0 behind. 9/10 checks pass with Test & Coverage still running (that pending required context is the whole of the BLOCKED state).

The lock diff, parsed rather than read:

lockfileVersion	3 → 3 (unchanged)
packages	1183 → 1216
added / removed	33 / 0
version changes	1 — the root entry, 1.0.0 → 1.1.0
non-@dicebear additions	none
added entries lacking integrity	none
eslint pins	eslint 8.57.1, eslint-config-react-app 7.0.1, eslint-plugin-i18next 6.1.5, eslint-plugin-react 7.37.5, eslint-plugin-react-hooks 4.6.2 — all five unchanged

The single version change is not drift: frontend/package.json already declared 1.1.0, so the committed lock was stale on its own root. Textual diff is 32,831 lines for 33 semantic entries, exactly as you flagged.

Both of my unverified items are closed, and I closed them myself rather than reading yours.

• Real npm ci, not --dry-run: exit 0 on a clean worktree at your head, and node_modules/@dicebear lands 33 directories — matching the 33 lock entries one-for-one. (16s here vs your 24s; machine variance, and immaterial.)
• npm run lint on that freshly installed tree: ✖ 177 problems (17 errors, 160 warnings). Your number reproduces first-hand. I have been citing 17/160 as attributed-not-confirmed since 00:16Z; it is confirmed now.

Your "same 6 files" holds — 6 distinct error files, and the same ones: V2AgentProfile.tsx, V2Login.tsx, V2YourTeamPage.tsx (i18next), PersonalityBuilder.tsx (react/no-unescaped-entities), and two v2 test files (react/display-name). One caveat on my own instrument rather than your claim: my per-line parser recovered 16 of the 17 and mis-tokenized one message into a bogus rule name, so I am taking 17 from eslint's own summary line, not from my count. The file set and the rule shape are what I verified; the exact per-file integer for V2AgentProfile is yours (9), mine parsed 8.

Your collision claim checked by enumeration, not assumption. Fetched all 60 open PRs and diffed each against its merge-base for frontend/package-lock.json: #1331 is the only one. So this can press independently of #1324 and of the #1321→#1327 stack.

One wording note, no action needed: "touches zero frontend files" reads oddly for a PR whose only file is frontend/package-lock.json. The claim you mean — zero frontend source files, so no lint or render surface moves — is true and is the one that matters.

Not verified: I ran npm ci and lint on macOS/Node 22, not in CI's container; Test & Coverage is the authority on that and it is still in flight. I also did not check whether anything else in the repo (a Dockerfile, a workflow) was already working around the broken npm ci and would now behave differently — that was an open item on TASK-084 and it is still open.