Enable Renovate's bun manager and weekly lock file maintenance #252

New issue

Closed

opened 2026-11-11 10:21:20 +01:00 by omp-deck · 0 comments

omp-deck commented

2026-11-11 10:21:20 +01:00

Collaborator

Problem

The web build prints Browserslist: browsers data (caniuse-lite) is N months old during RUN bun run build in the Dockerfile's web-build stage (Dockerfile:51). apps/web/postcss.config.cjs enables autoprefixer, which calls browserslist; with no browserslist key or .browserslistrc anywhere in the repo it resolves against the defaults query using the caniuse-lite version pinned in the lockfile (bun.lock:566, caniuse-lite@1.0.30001793). The warning fires purely on the release date of that pinned package.

Fixing this inside the Dockerfile is wrong: the only in-build fix would rewrite the lockfile during the image build, which contradicts bun install --frozen-lockfile (Dockerfile:43 and Dockerfile:160) and makes builds non-reproducible. The fix belongs to dependency maintenance, i.e. Renovate.

Renovate cannot do it today, for two independent reasons:

caniuse-lite is a transitive dependency — nothing in package.json, apps/web/package.json, or any other workspace manifest names it — and Renovate only raises updates for declared dependencies. The sole Renovate feature that advances transitive deps is lockFileMaintenance, which re-resolves the whole lockfile within the existing semver ranges. config:recommended (.renovaterc:4) leaves it disabled.
.renovaterc:16-22 restricts enabledManagers to npm, dockerfile, github-actions, custom.regex, renovate-config. The manager that owns bun.lock — and that implements lockFileMaintenance for it — is bun, which is absent from that list. Renovate's bun manager documentation (https://docs.renovatebot.com/modules/manager/bun/) states it supports lockFileMaintenance for bun.lockb and bun.lock, delegated to bun run as an external command.

A likely second symptom of (2): with the bun manager disabled, the npm manager picks up the package.json files and would edit semver ranges without regenerating bun.lock, so bun install --frozen-lockfile fails for such a branch in both CI (.github/workflows/ci.yml:37-38) and the Docker build. This is unverified — confirm first: git_log --author renovate returns no commits, no renovate/ branches exist locally, and a PR search for chore(deps) / fix(deps) returns nothing, so Renovate appears to have never opened a pull request in this repository. Adding bun to enabledManagers resolves this case regardless of whether it has already occurred.

End state: .renovaterc enables the bun manager and weekly lockFileMaintenance, so a chore(deps): lock file maintenance pull request refreshes bun.lock — caniuse-lite included — every Monday, gated by the existing CI matrix and merged by hand.

Plan

Approach

Both edits are to the single file .renovaterc and are independent of each other; apply them in one pass. No other file changes. .renovaterc is JSON (no comments permitted — it has none today, and $schema on line 2 is https://docs.renovatebot.com/renovate-schema.json), so preserve its 2-space indentation.

Let Renovate manage bun.lock. Add the string "bun" to the enabledManagers array at .renovaterc:16-22, positioned immediately after "npm". Resulting array, verbatim:
```
"enabledManagers": [
  "npm",
  "bun",
  "dockerfile",
  "github-actions",
  "custom.regex",
  "renovate-config"
],
```
Keep "npm". It is not redundant and it does not cause duplicate pull requests: the bun manager's documentation specifies that a package.json appearing in the bun manager's results is excluded from the npm manager's results unless an npm/pnpm/Yarn lock file is also found, and this repo has only bun.lock at the root. Retaining "npm" keeps coverage for any manifest the bun manager does not claim.
Enable weekly lock file maintenance. Add a top-level lockFileMaintenance object directly after the enabledManagers array and before "customManagers" (.renovaterc:23), verbatim:
```
"lockFileMaintenance": {
  "enabled": true
},
```
Do not add a schedule key here. Renovate's own default for lockFileMaintenance is ["before 4am on monday"], evaluated in the repo's configured timezone (Europe/Berlin, .renovaterc:11); writing it out would only duplicate a default and create a second place to keep in sync.

Do not add automerge. Nothing in this repository automerges today, and the weekly refresh is reviewed by hand.

Do not add commitMessage* overrides. The repository's history is conventional-commit (chore:, feat(server):, fix(web):), which Renovate auto-detects, producing chore(deps): lock file maintenance on branch renovate/lock-file-maintenance under the existing branchPrefix (.renovaterc:13).

No packageRules entry is needed: lockFileMaintenance as a top-level object applies wherever a supported lock file exists, which in this repo is bun.lock alone. The dockerfile, github-actions, custom.regex, and renovate-config managers have no lock files and are unaffected.

Scope boundary: this plan does not touch the browserslist query itself — apps/web deliberately keeps no explicit browserslist targets and continues to resolve defaults.

Critical files & anchors

.renovaterc — the enabledManagers array (lines 16-22) and the gap before "customManagers" (line 23). The only file edited.
.forgejo/workflows/renovate.yml:38 — pins the Renovate container to renovate/renovate:44.14.12; use that same version when validating the config so the validator matches the version that will consume it.

Verification

Run from the repository root.

Config is valid for the exact Renovate version that runs it. npx --yes --package renovate@44.14.12 renovate-config-validator .renovaterc

Expected observable output: a line containing Validating .renovaterc followed by Config validated successfully, and exit status 0. A rejected enabledManagers member (e.g. a typo such as "buns") or a malformed lockFileMaintenance object makes the validator print an error and exit non-zero, which is the specific failure this check exists to catch. Requires network access to the npm registry; npx is present at /usr/bin/npx.
The repository still installs cleanly — the edit touches no dependency, so the lockfile must be untouched: bun install --frozen-lockfile

Expected: completes without the lockfile had changes, but lockfile is frozen error, confirming the change is config-only.
Post-merge observable (not runnable at implementation time, stated so the outcome is checkable later): on the first Monday after merge, the hourly Renovate workflow (.forgejo/workflows/renovate.yml:4-5) opens a pull request titled chore(deps): lock file maintenance from branch renovate/lock-file-maintenance, whose diff modifies bun.lock and no package.json. Merging it advances caniuse-lite beyond 1.0.30001793 (bun.lock:566) and the browserslist staleness warning disappears from the web-build stage output of docker build -t omp-deck ..

To observe it sooner, run the Renovate workflow out of schedule via its workflow_dispatch trigger (.forgejo/workflows/renovate.yml:10-28) with dryRun: full and logLevel: debug; the log then reports the lock file maintenance branch it would create without pushing it. Dispatching that workflow requires Forgejo Actions access, which is outside this plan's tooling — if it is unavailable, rely on the scheduled run.

Assumptions & contingencies

Renovate's Forgejo token can create pull requests in this repository. If it cannot, no lock-file-maintenance PR appears and the config change is inert but harmless; the validator check in Verification still passes. Diagnosing the token is out of scope here — report it rather than changing credentials.
If renovate-config-validator rejects "bun" as an enabledManagers member (it will not for 44.14.12, where the bun manager is documented), do not drop the manager: instead pin the validator invocation to the version named in .forgejo/workflows/renovate.yml:38 and re-run, since an older globally resolved Renovate is then the cause.
If the first scheduled lock-file-maintenance PR fails CI, do not disable lockFileMaintenance again — the failure is a genuine incompatibility inside an existing semver range, and the fix belongs in the offending dependency's constraint in the relevant package.json.

## Problem The web build prints `Browserslist: browsers data (caniuse-lite) is N months old` during `RUN bun run build` in the Dockerfile's `web-build` stage (`Dockerfile:51`). `apps/web/postcss.config.cjs` enables `autoprefixer`, which calls browserslist; with no `browserslist` key or `.browserslistrc` anywhere in the repo it resolves against the `defaults` query using the `caniuse-lite` version pinned in the lockfile (`bun.lock:566`, `caniuse-lite@1.0.30001793`). The warning fires purely on the release date of that pinned package. Fixing this inside the Dockerfile is wrong: the only in-build fix would rewrite the lockfile during the image build, which contradicts `bun install --frozen-lockfile` (`Dockerfile:43` and `Dockerfile:160`) and makes builds non-reproducible. The fix belongs to dependency maintenance, i.e. Renovate. Renovate cannot do it today, for two independent reasons: 1. `caniuse-lite` is a transitive dependency — nothing in `package.json`, `apps/web/package.json`, or any other workspace manifest names it — and Renovate only raises updates for declared dependencies. The sole Renovate feature that advances transitive deps is `lockFileMaintenance`, which re-resolves the whole lockfile within the existing semver ranges. `config:recommended` (`.renovaterc:4`) leaves it disabled. 2. `.renovaterc:16-22` restricts `enabledManagers` to `npm`, `dockerfile`, `github-actions`, `custom.regex`, `renovate-config`. The manager that owns `bun.lock` — and that implements `lockFileMaintenance` for it — is `bun`, which is absent from that list. Renovate's bun manager documentation (<https://docs.renovatebot.com/modules/manager/bun/>) states it supports `lockFileMaintenance` for `bun.lockb` and `bun.lock`, delegated to `bun` run as an external command. A likely second symptom of (2): with the bun manager disabled, the npm manager picks up the `package.json` files and would edit semver ranges without regenerating `bun.lock`, so `bun install --frozen-lockfile` fails for such a branch in both CI (`.github/workflows/ci.yml:37-38`) and the Docker build. This is **unverified — confirm first**: `git_log --author renovate` returns no commits, no `renovate/` branches exist locally, and a PR search for `chore(deps)` / `fix(deps)` returns nothing, so Renovate appears to have never opened a pull request in this repository. Adding `bun` to `enabledManagers` resolves this case regardless of whether it has already occurred. End state: `.renovaterc` enables the `bun` manager and weekly `lockFileMaintenance`, so a `chore(deps): lock file maintenance` pull request refreshes `bun.lock` — `caniuse-lite` included — every Monday, gated by the existing CI matrix and merged by hand. ## Plan ### Approach Both edits are to the single file `.renovaterc` and are independent of each other; apply them in one pass. No other file changes. `.renovaterc` is JSON (no comments permitted — it has none today, and `$schema` on line 2 is `https://docs.renovatebot.com/renovate-schema.json`), so preserve its 2-space indentation. 1. **Let Renovate manage `bun.lock`.** Add the string `"bun"` to the `enabledManagers` array at `.renovaterc:16-22`, positioned immediately after `"npm"`. Resulting array, verbatim: ```json "enabledManagers": [ "npm", "bun", "dockerfile", "github-actions", "custom.regex", "renovate-config" ], ``` Keep `"npm"`. It is not redundant and it does not cause duplicate pull requests: the bun manager's documentation specifies that a `package.json` appearing in the bun manager's results is excluded from the npm manager's results unless an npm/pnpm/Yarn lock file is also found, and this repo has only `bun.lock` at the root. Retaining `"npm"` keeps coverage for any manifest the bun manager does not claim. 2. **Enable weekly lock file maintenance.** Add a top-level `lockFileMaintenance` object directly after the `enabledManagers` array and before `"customManagers"` (`.renovaterc:23`), verbatim: ```json "lockFileMaintenance": { "enabled": true }, ``` Do **not** add a `schedule` key here. Renovate's own default for `lockFileMaintenance` is `["before 4am on monday"]`, evaluated in the repo's configured `timezone` (`Europe/Berlin`, `.renovaterc:11`); writing it out would only duplicate a default and create a second place to keep in sync. Do **not** add `automerge`. Nothing in this repository automerges today, and the weekly refresh is reviewed by hand. Do **not** add `commitMessage*` overrides. The repository's history is conventional-commit (`chore:`, `feat(server):`, `fix(web):`), which Renovate auto-detects, producing `chore(deps): lock file maintenance` on branch `renovate/lock-file-maintenance` under the existing `branchPrefix` (`.renovaterc:13`). No `packageRules` entry is needed: `lockFileMaintenance` as a top-level object applies wherever a supported lock file exists, which in this repo is `bun.lock` alone. The `dockerfile`, `github-actions`, `custom.regex`, and `renovate-config` managers have no lock files and are unaffected. Scope boundary: this plan does not touch the browserslist query itself — `apps/web` deliberately keeps no explicit `browserslist` targets and continues to resolve `defaults`. ### Critical files & anchors - `.renovaterc` — the `enabledManagers` array (lines 16-22) and the gap before `"customManagers"` (line 23). The only file edited. - `.forgejo/workflows/renovate.yml:38` — pins the Renovate container to `renovate/renovate:44.14.12`; use that same version when validating the config so the validator matches the version that will consume it. ### Verification Run from the repository root. 1. **Config is valid for the exact Renovate version that runs it.** `npx --yes --package renovate@44.14.12 renovate-config-validator .renovaterc` Expected observable output: a line containing `Validating .renovaterc` followed by `Config validated successfully`, and exit status 0. A rejected `enabledManagers` member (e.g. a typo such as `"buns"`) or a malformed `lockFileMaintenance` object makes the validator print an error and exit non-zero, which is the specific failure this check exists to catch. Requires network access to the npm registry; `npx` is present at `/usr/bin/npx`. 2. **The repository still installs cleanly** — the edit touches no dependency, so the lockfile must be untouched: `bun install --frozen-lockfile` Expected: completes without the `lockfile had changes, but lockfile is frozen` error, confirming the change is config-only. 3. **Post-merge observable** (not runnable at implementation time, stated so the outcome is checkable later): on the first Monday after merge, the hourly Renovate workflow (`.forgejo/workflows/renovate.yml:4-5`) opens a pull request titled `chore(deps): lock file maintenance` from branch `renovate/lock-file-maintenance`, whose diff modifies `bun.lock` and no `package.json`. Merging it advances `caniuse-lite` beyond `1.0.30001793` (`bun.lock:566`) and the browserslist staleness warning disappears from the `web-build` stage output of `docker build -t omp-deck .`. To observe it sooner, run the Renovate workflow out of schedule via its `workflow_dispatch` trigger (`.forgejo/workflows/renovate.yml:10-28`) with `dryRun: full` and `logLevel: debug`; the log then reports the lock file maintenance branch it would create without pushing it. Dispatching that workflow requires Forgejo Actions access, which is outside this plan's tooling — if it is unavailable, rely on the scheduled run. ### Assumptions & contingencies - **Renovate's Forgejo token can create pull requests in this repository.** If it cannot, no lock-file-maintenance PR appears and the config change is inert but harmless; the validator check in Verification still passes. Diagnosing the token is out of scope here — report it rather than changing credentials. - **If `renovate-config-validator` rejects `"bun"` as an `enabledManagers` member** (it will not for 44.14.12, where the bun manager is documented), do not drop the manager: instead pin the validator invocation to the version named in `.forgejo/workflows/renovate.yml:38` and re-run, since an older globally resolved Renovate is then the cause. - **If the first scheduled lock-file-maintenance PR fails CI**, do not disable `lockFileMaintenance` again — the failure is a genuine incompatibility inside an existing semver range, and the fix belongs in the offending dependency's constraint in the relevant `package.json`.