fix: refresh yarn lock for immutable install

[martinothamar-agent]

Summary

• refresh yarn.lock so Yarn 4.12.0 merges duplicate axe-core entries
• fixes the yarn --immutable failure currently seen on main Docker/frontend builds

Why

main is failing in https://github.com/Altinn/altinn-studio/actions/runs/26171754766/job/76991119339 because Yarn wants to normalize the axe-core@npm:4.11.4 and axe-core@npm:^4.2.0 lock entries, but immutable installs reject that generated lockfile change.

Testing

• node .yarn/releases/yarn-4.12.0.cjs install --immutable --inline-builds

cc @martinothamar

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c468efd3-b429-4148-9fa6-d9f9fad08144

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[martinothamar]

when did this break earlier?

[martinothamar-agent]

It looks like it was introduced by f2fcf3fd03 / #18818 (chore: add a11y addon for storybook in form component), merged around 2026-05-20 13:20 UTC. That PR added @storybook/addon-a11y@10.2.16, which depends on axe-core: ^4.2.0, and the lockfile got a separate axe-core@npm:^4.2.0 entry instead of merging it with the existing axe-core@npm:4.11.4 entry.

The previous relevant main frontend run I found before that was green: 04ea309b3a at 2026-05-20 12:46 UTC. The first main run I found after #18818 was App Frontend - Lighthouse CI at f2fcf3fd03 (https://github.com/Altinn/altinn-studio/actions/runs/26165224113), but its build step hit the frontend cache, so it did not expose the immutable install problem.

The first visible failure with the exact yarn --immutable / axe-core diff I found is the Designer deploy Docker build at ecc6e6c0ea (https://github.com/Altinn/altinn-studio/actions/runs/26171754766/job/76991119339). That run includes #18818 in its ancestry and fails inside src/Designer/Dockerfile at RUN yarn --immutable.

Locally, the same failure reproduces on current main with node .yarn/releases/yarn-4.12.0.cjs install --immutable --inline-builds; after this PR's lockfile normalization the same command passes with only the existing peer warnings.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.84%. Comparing base (50540fa) to head (8922569).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #18895   +/-   ##
=======================================
  Coverage   95.84%   95.84%           
=======================================
  Files        3018     3022    +4     
  Lines       39575    39655   +80     
  Branches     4849     4875   +26     
=======================================
+ Hits        37931    38009   +78     
- Misses       1230     1231    +1     
- Partials      414      415    +1     

☔ View full report in Codecov by Sentry.
📢 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.