Skip to content

fix(ci): pin yarn to 4.10.3 and regenerate lockfile - #381

Merged
JosephSamirL merged 1 commit into
main-convertfrom
fix/yarn-lock-version-mismatch
May 20, 2026
Merged

fix(ci): pin yarn to 4.10.3 and regenerate lockfile#381
JosephSamirL merged 1 commit into
main-convertfrom
fix/yarn-lock-version-mismatch

Conversation

@abbaseya

Copy link
Copy Markdown
Collaborator

Summary

Staging deploys for convertcom/backend are failing on the V1 tracking build because of a lockfile-format mismatch in this submodule.

Symptom — backend CI build log:

➤ YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.
__metadata:
-  version: 9
+  version: 8

Root cause — commit a85ad99 ("chore: update yarn lock") was generated with yarn >=4.11, which writes lockfile metadata version: 9. But the backend's V1 tracking build runs yarn install in immutable mode under yarn 4.10.3 (per public/js/tracking/package.json's packageManager field), which writes version: 8. The backend Ant target build_tracking_dist_v1 does git submodule update --remote javascript-sdk, so it always pulls main-convert HEAD regardless of the pinned gitlink — meaning this lockfile breaks every backend staging deploy until fixed here.

Changes

  • package.json: add "packageManager": "yarn@4.10.3+sha512..." matching the backend tracking workspace. Locks the toolchain so future installs by any contributor don't silently drift the lockfile version.
  • yarn.lock: regenerated with yarn 4.10.3 (the only diff vs. previous HEAD is __metadata.version: 98).

Test plan

  • Verified yarn install --immutable (what CI runs) completes with warnings only — no YN0028
  • Re-run backend staging deploy after merge to confirm build_tracking_dist_v1 passes

The yarn.lock on main-convert was bumped to lockfile metadata
`version: 9` by a local install with yarn >=4.11. The backend's V1
tracking build runs `yarn install` in immutable mode under yarn
4.10.3 (per `public/js/tracking/package.json` packageManager field),
which writes `version: 8` lockfiles — triggering YN0028 and failing
staging deploys.

Pinning `packageManager: yarn@4.10.3` here makes the toolchain
explicit and prevents future drift when contributors run install
with a newer yarn.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@abbaseya abbaseya self-assigned this May 20, 2026
@abbaseya
abbaseya requested a review from DmytroConvert May 20, 2026 19:41
@sonarqubecloud

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the package.json file to include the packageManager field, specifying Yarn version 4.10.3. I have no feedback to provide.

@abbaseya
abbaseya requested a review from a team May 20, 2026 20:03
@JosephSamirL
JosephSamirL merged commit d4e3ef4 into main-convert May 20, 2026
6 checks passed
@JosephSamirL
JosephSamirL deleted the fix/yarn-lock-version-mismatch branch May 20, 2026 21:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants