fix(deps): restore yarn.lock after the qs bump, which broke every frozen install

Merged
EV
18d ago
+64-64

Problem

Every develop Build since #11517 fails at build-monorepo-root → Install dependencies (run 40604699636 on c915cc61b0):

warning Lockfile has incorrect entry for "@angular-devkit/architect@0.2202.2". Ignoring it.
warning Lockfile has incorrect entry for "@angular-devkit/core@22.2.2". Ignoring it.
error Your lockfile needs to be updated, but yarn was run with `--frozen-lockfile`.

#11517 (Dependabot, qs 6.16.0 → 6.16.1) regenerated yarn.lock and also moved entries it shouldn't have. The exact-pinned key @angular-devkit/architect@0.2202.2 now resolves to 0.2202.4, and @angular-devkit/core resolves to 22.2.4 under its 22.2.2 pin. Yarn treats those as incorrect entries. The other jobs then fail because no node_modules archive is produced.

Bisect: #11517 is the only change to yarn.lock or any package.json between c034556815, where CI's install passed, and c915cc61b0, where it fails.

Fix

  • yarn.lock is now c034556815's, the last one CI installed, with only the qs change re-applied: qs@^6.16.1 is merged into the shared qs entry at 6.16.1, the same content as #11517's qs hunk.
  • Locally, yarn install --frozen-lockfile on this lockfile resolves cleanly: no incorrect entries, and it goes on to fetch instead of erroring. Before this fix, the same command reproduced the CI error exactly.
  • No localhost registry URLs (grep -c localhost yarn.lock = 0).

šŸ¤– Generated with Claude Code


Summary by cubic

Restores yarn.lock to the last version CI successfully installed, with only the qs 6.16.0 → 6.16.1 bump re-applied. The Dependabot qs update had regenerated the lockfile and changed unrelated entries, so Yarn reported incorrect lockfile entries and every yarn install --frozen-lockfile on develop failed.

  • Rolls back unintended version changes (for example @angular-devkit/architect no longer resolves 0.2202.4 under its 0.2202.2 pin) while keeping the qs update.
  • yarn install --frozen-lockfile resolves cleanly against the restored lockfile.