[deps]: Lock file maintenance

[renovate]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "every 2nd week starting on the 2 week of the year before 4am on Monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[cloudflare-workers-and-pages]

Deploying contributing-docs with    Cloudflare Pages

Latest commit:	8677fba
Status:	🚫  Build failed.

View logs

[bitwarden-bot]

Internal tracking:

• ID: PM-34951
• Link: https://bitwarden.atlassian.net/browse/PM-34951

[github-actions]

Checkmarx One – Scan Summary & Details – 5373fe5d-ee6a-4a8f-82bc-a43ee8c6cf14

Great job! No new security vulnerabilities introduced in this pull request

[jprusik]

See also:
bitwarden/test-the-web#408

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[bensbits91]

In addition to the intended lock file maintenance, this PR also includes the following changes (to address failing build checks):

• Update docusaurus.config.ts to move onBrokenMarkdownLinks to newly-correct location. Why? In Docusaurus 3.9.2, onBrokenMarkdownLinks was moved from a top-level config option to markdown.hooks.onBrokenMarkdownLinks. Keeping it at the top level causes the build to fail with an unrecognized option error.

• Update .nvmrc to pin nvm to version 22.14.0. Why? Our package.json already declares engines: "~22.14.0", but .nvmrc was set to 22, which CI resolves to the latest Node 22.x release. Pinning .nvmrc to 22.14.0 aligns the CI environment with the declared engine requirement and eliminates the EBADENGINE warning during npm ci.

• Update package.json to pin webpack to 5.105.4. Why? Renovate's lock file maintenance bumped webpack from 5.105.4 to 5.106.2, which introduced a breaking change to webpack's ProgressPlugin schema. The new schema rejects the { name, color, reporters, reporter } options that webpackbar 6.0.1 (a Docusaurus internal dependency) passes to it, causing the build to fail. Pinning webpack to 5.105.4 restores the previously working version until Docusaurus ships a fix for the webpackbar compatibility.

[jprusik]

One potentially blocking concern around package overrides, but everything else looks good to me (on the basis of similar dep maintenance work in test-the-web)

[jprusik]

I'm open to other folks' thoughts, but I don't think we should utilize this override; Docusaurus is likely to resolve this, imo.

In test-the-web, I opted to mark the package-lock update as blocked
bitwarden/test-the-web#423 (comment)

[bensbits91]

Currently blocked by facebook/docusaurus#11923

[bensbits91]

Note: At least one of my previous issues has been resolved. Instead of trying to manually revert each fix to check for resolution, I think it's cleaner to allow renovate to rebase and wipe out my changes, then check for remaining issues. However, we might need to bump docusaurus to 3.10.1 first.

We currently have pinned to Docusaurus 3.10.0 (no ^), so Renovate's lock file maintenance alone won't pull in 3.10.1. I think we need an actual version bump of @docusaurus/core and @docusaurus/preset-classic from 3.10.0 → 3.10.1 (or higher).

@jprusik do you think it would be better to:

(a) Wait — Renovate will eventually open a separate PR bumping Docusaurus to 3.10.1+. (I don't see this PR yet.) Once that merges into main, this lock file maintenance PR (after a rebase) should build cleanly.

(b) Bump Docusaurus on main first — separate small PR updating package.json from 3.10.0 → 3.10.1. Then rebase this Renovate PR.

(c) Bump Docusaurus inside this Renovate PR — least clean, mixes a dependency upgrade into a lock-file-maintenance PR.

ETA: I discussed with Jon and we determined it's better to wait for the docusaurus bump to be completed before handling this PR.