[deps]: Pin node to 20.15.0 - autoclosed

[renovate]

This PR contains the following updates:

Package	Update	Change
node (source)	pin	v20 -> 20.15.0

Add the preset :preserveSemverRanges to your config if you don't want to pin your dependencies.

---

Configuration

📅 Schedule: Branch creation - "every 2nd week starting on the 2 week of the year before 4am on Monday" (UTC), Automerge - At any time (no schedule defined).

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

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

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

---

This PR has been generated by Mend Renovate. View repository job log here.

[cloudflare-workers-and-pages]

Deploying contributing-docs with    Cloudflare Pages

Latest commit:	a69a061
Status:	✅  Deploy successful!
Preview URL:	https://07f6364b.contributing-docs.pages.dev
Branch Preview URL:	https://renovate-pin-dependencies.contributing-docs.pages.dev

View logs

[bitwarden-bot]

Checkmarx One – Scan Summary & Details – 8dd6220a-7561-41e4-8a9d-7dbfa1f50bcc

No New Or Fixed Issues Found

[Hinton]

@jprusik this seems to be due to #370. I don't think we want to pin this, and we're fairly restrictive of when we bump the version in nvm and package.json.

[withinfocus]

@Hinton Jon and I were working together to roll this out anywhere NVM is used, and I called out that our pinning policy could conflict with it; our result was "eh, why not?" given the frequency this runs. The alternative is an overriding package rule e.g.:

{
  "matchManagers": ["nvm"],
  "rangeStrategy": "replace"
}

(untested) that we could try, but that's something to maintain on its own to me. I see this tracking with our normal rules of operation, and we can stay up on explicit Node installations locally.

[Hinton]

@Hinton Jon and I were working together to roll this out anywhere NVM is used, and I called out that our pinning policy could conflict with it; our result was "eh, why not?" given the frequency this runs. The alternative is an overriding package rule e.g.:

{
  "matchManagers": ["nvm"],
  "rangeStrategy": "replace"
}

(untested) that we could try, but that's something to maintain on its own to me. I see this tracking with our normal rules of operation, and we can stay up on explicit Node installations locally.

Fair, I guess I don't really like it since it's a bit of a maintenance burden little gain. We don't really have any tooling in place to enforce nvm is used and the ranges in package.json should be vague.