chore(deps): lock file maintenance #39

Closed

renovate-bot wants to merge 1 commit from renovate/lock-file-maintenance into main

pull from: renovate/lock-file-maintenance

merge into: rbrooks:main

rbrooks:main

Conversation 1 Commits 1 Files changed 2 +1369 -1383

renovate-bot commented 2026-07-13 05:19:00 +00:00

Contributor

Copy link

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
  • "before 6am 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 has been generated by Mend 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 - "before 6am 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](https://github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yNDkuNSIsInVwZGF0ZWRJblZlciI6IjQzLjI0OS41IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

renovate-bot added 1 commit 2026-07-13 05:19:00 +00:00

chore(deps): lock file maintenance 37474fed4d

renovate-bot force-pushed renovate/lock-file-maintenance from 37474fed4d to 52b362d729 2026-07-16 05:25:05 +00:00 Compare

renovate-bot force-pushed renovate/lock-file-maintenance from 52b362d729 to 0c05e44195 2026-07-25 01:24:12 +00:00 Compare

rbrooks referenced this pull request from a commit 2026-08-31 02:55:29 +00:00

CI: derive the Playwright image tag from the lockfile (#38, #39)

claude-bot referenced this pull request 2026-08-31 03:13:10 +00:00

Clear the 6 open dependency advisories, and decide what the audit job gates #81

renovate-bot force-pushed renovate/lock-file-maintenance from 0c05e44195 to 8858d39d45 2026-08-31 06:14:17 +00:00 Compare

renovate-bot force-pushed renovate/lock-file-maintenance from 8858d39d45 to 6467bde558 2026-08-31 18:14:17 +00:00 Compare

claude-bot referenced this pull request 2026-08-31 19:54:33 +00:00

Clear the 6 open dependency advisories, and decide what the audit job gates #81

claude-bot commented 2026-08-31 20:06:52 +00:00

Contributor

Copy link

Closing so Renovate regenerates this against current main.

Why not merge it as-is

This PR was green (run #7799), but that run was against a base before #87 merged. Its lockfile refresh was computed with react-router-dom at v6, and main is now on v7.

Forgejo reports it mergeable, but a textually-clean merge could still leave package.json declaring ^7.0.0 while the refreshed lockfile pins the v6 tree — which breaks npm ci and would only surface after landing on main. A lockfile computed against superseded inputs is not safe to merge just because git can apply it.

Why not hand-rebase it

That was the approach for #38 and #37, but it does not work here. Regenerating a lockfile requires npm, which is available neither on this machine nor on the dev host. And even with npm, npm install --package-lock-only resolves everything to the newest matching version, bypassing the minimumReleaseAge: "3 days" quarantine added in #56 for supply-chain safety. Undoing a security control to save waiting is not a good trade.

Why closing is safe here specifically

I have deliberately avoided closing Renovate PRs elsewhere in this queue, because a closed-unmerged PR is normally treated as a rejected update and may never be recreated.

lockFileMaintenance is the exception, and this PR's own body says so:

👻 Immortal: This PR will be recreated if closed unmerged.

So closing triggers exactly the regeneration we want, against the current main, with the quarantine applied — rather than my forcing a stale lockfile through.

What it still needs to clear

Three high advisories from #81 remain and all clear together via this refresh:

• brace-expansion (high ×3)
• js-yaml (high)
• nanoid (high ×2)

postcss was cleared by #38 and both react-router moderates by #87, so this is the last piece of that issue's part 1.

Closing so Renovate regenerates this against current `main`. ## Why not merge it as-is This PR was green (run #7799), but that run was against a base **before #87 merged**. Its lockfile refresh was computed with `react-router-dom` at **v6**, and `main` is now on **v7**. Forgejo reports it mergeable, but a textually-clean merge could still leave `package.json` declaring `^7.0.0` while the refreshed lockfile pins the v6 tree — which breaks `npm ci` and would only surface after landing on `main`. A lockfile computed against superseded inputs is not safe to merge just because git can apply it. ## Why not hand-rebase it That was the approach for #38 and #37, but it does not work here. Regenerating a lockfile requires npm, which is available neither on this machine nor on the dev host. And even with npm, `npm install --package-lock-only` resolves everything to the newest matching version, **bypassing the `minimumReleaseAge: "3 days"` quarantine** added in #56 for supply-chain safety. Undoing a security control to save waiting is not a good trade. ## Why closing is safe here specifically I have deliberately avoided closing Renovate PRs elsewhere in this queue, because a closed-unmerged PR is normally treated as a rejected update and may never be recreated. **`lockFileMaintenance` is the exception, and this PR's own body says so:** > 👻 **Immortal**: This PR will be recreated if closed unmerged. So closing triggers exactly the regeneration we want, against the current `main`, with the quarantine applied — rather than my forcing a stale lockfile through. ## What it still needs to clear Three high advisories from #81 remain and all clear together via this refresh: - `brace-expansion` (high ×3) - `js-yaml` (high) - `nanoid` (high ×2) `postcss` was cleared by #38 and both `react-router` moderates by #87, so this is the last piece of that issue's part 1.

claude-bot closed this pull request 2026-08-31 20:06:56 +00:00

claude-bot referenced this pull request 2026-09-01 03:11:53 +00:00

Clear the 6 open dependency advisories, and decide what the audit job gates #81

claude-bot referenced this pull request 2026-09-01 03:20:16 +00:00

Clear the 6 open dependency advisories, and decide what the audit job gates #81

claude-bot referenced this pull request 2026-09-01 15:14:46 +00:00

Clear the 6 open dependency advisories, and decide what the audit job gates #81

All checks were successful

Hide checks

CI / Python lint & type-check (pull_request) Successful in 1m3s

Required

Details

CI / Alembic migration check (pull_request) Successful in 1m59s

Required

Details

CI / Frontend lint, test & build (pull_request) Successful in 3m42s

Required

Details

CI / Python tests (pull_request) Successful in 5m30s

Required

Details

CI / Docker build, health smoke & E2E (pull_request) Successful in 2m2s

Required

Details

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area/ai

AI suggestion pipeline

  

area/backend

FastAPI / Python backend

  

area/frontend

React / Vite frontend

  

area/infra

Docker, deployment, and infrastructure

  

area/scheduler

Scheduler and time envelope

  

area/wled

WLED controller integration

  

good-first-issue

Good for newcomers

  

priority/high

Blocks release or high impact

  

priority/low

Nice to have

  

priority/medium

Should be done soon

  

type/bug

Something isn't working

  

type/chore

Maintenance, release, or housekeeping

  

type/ci-cd

CI/CD pipeline, build, or release automation

  

type/docs

Documentation

  

type/feature

New capability or enhancement

  

type/qa

Testing, validation, or quality assurance

  

v1.0.0

Target release: v1.0.0

  

v1.1.0

Target release: v1.1.0

  

v1.2.0

Target release: v1.2.0

  

v2.0.0

Target release: v2.0.0

No labels

area/ai

area/backend

area/frontend

area/infra

area/scheduler

area/wled

good-first-issue

priority/high

priority/low

priority/medium

type/bug

type/chore

type/ci-cd

type/docs

type/feature

type/qa

v1.0.0

v1.1.0

v1.2.0

v2.0.0

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

rbrooks/Iris-WLED!39

No description provided.