chore(deps): update devbox packages across all projects

[mikeland73]

Summary

Refreshes the pinned package versions in every devbox.json project in the repo, then reconciles shared entries with devbox update --sync-lock.

52 devbox.lock files changed. Of 59 package bumps the refresh produced, 52 are kept and 7 were pinned back after CI (see What got pinned back below).

Highlights of what's kept:

Area	Bumps
Root toolchain	git 2.54.0 → 2.55.0, fd 10.4.2 → 10.5.0, nodejs-slim 26.7.0 → 26.8.1
Node	nodejs 25.8.1 → 26.8.1, nodejs@18 18.19.1 → 18.20.8, bun 1.0.33 → 1.3.13, corepack 0.35.0 → 0.36.0
Python	python 3.12.1 → 3.14.4, python3 3.11.7 → 3.12.8, poetry 1.7.1 → 2.4.1, pipenv 2023.2.4 → 2026.5.1
PHP	php 8.3.3 → 8.5.9, php81Packages.composer 2.6.6 → 2.8.12, php83Extensions.imagick 3.7.0 → 3.8.1, xdebug 3.3.1 → 3.5.3
Databases	postgresql 17.5 → 18.6, redis 7.2.4 → 8.10.1, valkey 7.2.5 → 9.1.1, mariadb 11.0.4 → 11.8.8, mysql80 8.0.36 → 8.0.45
Servers	nginx 1.24.0 → 1.30.4, caddy 2.7.6 → 2.11.4, apache 2.4.58 → 2.4.68
Haskell / JVM	ghc 9.4.8 → 9.10.3, cabal-install 3.10.2.1 → 3.16.1.0, gradle 8.6 → 8.14.4, maven 3.9.6 → 3.9.16
Other	ruby 4.0.2 → 4.0.6, rustup 1.26.0 → 1.29.0, minikube 1.32.0 → 1.38.1, fnm 1.35.1 → 1.39.0, openssl 3.0.13 → 3.6.0, R packages

--sync-lock also harmonised the shared github:NixOS/nixpkgs/nixpkgs-unstable stdenv entry — all 21 lockfiles carrying it now agree on the same pin (2026-08-03), where they previously diverged.

Unversioned "source": "nixpkg" entries (e.g. kubectl, docker, pdm) are untouched, which is what devbox update does for them.

What got pinned back

CI found six broken examples; each was root-caused from the job logs.

Upstream problems with the new package — pinned back, rest of the lockfile keeps its bumps:

Package	Where	Why
go 1.27.0 → 1.26.3	root	Go 1.27's gofmt reformats nix/flake/flakeref_test.go, and golangci-lint v1.64.8 (pinned in go.mod) panicked five analyzers on 1.27 ASTs. Worth revisiting once golangci-lint supports 1.27.
dotnet-sdk 8.0.424 → 6.0.418	csharp, fsharp	libhostfxr.so resolves against the runner's system glibc and needs GLIBC_ABI_GNU2_TLS, which it doesn't export
jdk@19 19-ga → 19.0.2+7	java/gradle, java/maven	Package 'openjdk-19-ga' … is marked as insecure, refusing to evaluate. JDK 19 is EOL — moving these examples to a supported JDK is the durable fix, but that's an example change, not a lockfile refresh.
libffi 3.8.0 → 3.4.4	jekyll	3.8.0 has no macOS build at all upstream; taking it would break the example on every Mac
stack 3.9.3 → 2.13.1	haskell	3.9.3 has no aarch64-darwin build upstream, dropping Apple Silicon

gradle 8.14.4, maven 3.9.16 and binutils 2.46 are unaffected by the jdk pin and stay.

Bumps that were fine — the example needed updating instead:

• poetry-pyproject-subdir: Poetry 2.x makes No file/folder found for package poetry-pyproject-subdir-service a hard error where 1.7 only warned. This example uses Poetry purely for dependency management and has no service/ package, so it now declares package-mode = false, Poetry's own suggested remedy. poetry-demo has a real package directory and already passes on 2.4.1, so poetry stays at 2.4.1 in both.
• stacks/rails: the Gemfile pinned ruby "4.0.2" exactly, so ruby 4.0.6 failed with Your Ruby version is 4.0.6, but your Gemfile specified 4.0.2. Moved the pin and Gemfile.lock's RUBY VERSION to 4.0.6, keeping the bump.

Platform coverage — please read before merging

Beyond the two reverts above, this refresh drops 30 x86_64-darwin blocks from systems maps across ~19 lockfiles, because the newer versions no longer publish an Intel-mac build upstream. Affected packages include redis, postgresql, mysql84, valkey, python311, nginx, php, fd and git.

This is inherent to taking the upgrade, not an artifact of how the update was run — search.devbox.sh resolves all platforms server-side, and querying it directly confirms e.g. fd 10.4.2 has all four systems while 10.5.0 has three. Reverting all of them would undo most of this PR, so they stand. Flagging it explicitly so it isn't a silent consequence; happy to pin specific packages back if Intel-mac coverage matters more than the version bump.

How was it tested?

• CI (cli-tests), including the project-tests-only matrix that builds every example. Each failure was root-caused from job logs rather than guessed at, and re-run after each fix.
• Every changed lockfile validated as well-formed JSON; round-trip formatting is byte-identical to devbox's own writer.
• Verified no machine-specific absolute paths leaked in. devbox update resolves local flake refs (path:my-php-flake#php and friends in examples/flakes/*) to an absolute path on the machine that ran it; those four entries were restored to their committed values.

One caveat: Gemfile.lock's RUBY VERSION was written as ruby 4.0.6p0, guessing the patchlevel. Bundler's hard check is the Gemfile directive and bin/bundle install rewrites that block, so it should be inert, but it's worth a glance.

Note on scope

The sandbox that produced this branch blocks api.github.com for repositories outside this one, so nix flake metadata github:NixOS/nixpkgs/nixpkgs-unstable could not run. The nixpkgs-unstable stdenv entry was therefore not re-resolved against upstream — only synced to the newest value already in the repo. Everything else resolved normally through search.devbox.sh. A maintainer re-running devbox update --all-projects locally would additionally advance that one pin.

Community Contribution License

All community contributions in this pull request are licensed to the project
maintainers under the terms of the
Apache 2 License.

By creating this pull request, I represent that I have the right to license the
contributions to the project maintainers under the Apache 2 License as stated in
the
Community Contribution License.

🤖 Generated with Claude Code

https://claude.ai/code/session_015RaccMofrSPEL7v8RzpoWb

[mikeland73]

golangci-lint (ubuntu-latest) failed on e33e794. Root cause was the go@latest 1.26.3 → 1.27.0 bump in the root devbox.lock — this PR touches only lockfiles, so the Go version was the sole variable.

Two symptoms, one cause:

1. The exit-1: nix/flake/flakeref_test.go:63:1: File is not properly formatted (gofmt). Go 1.27's gofmt changed the alignment heuristic for composite literals, so a file correctly formatted for the pinned toolchain reads as unformatted.
2. Five staticcheck analyzers panicked while building IR from Go 1.27 syntax — buildir with unexpected expr: *ast.KeyValueExpr, then typedness, nilness, fact_purity and SA5012 cascading off it. Those analyzers silently produced no findings.

Both come from golangci-lint v1.64.8, which go.mod pins as a tool and which predates Go 1.27. Since go.mod also declares go 1.26.1, reformatting the test file for the newer gofmt would break devbox run lint for anyone on the pinned toolchain, and would leave the analyzer panics — and the lost lint coverage — in place. Upgrading golangci-lint is a separate change, out of scope for a lockfile refresh.

So go is pinned back to 1.26.3 in 773d8be. Everything else in the update stands, including fd 10.4.2 → 10.5.0, git 2.54.0 → 2.55.0 and nodejs-slim 26.7.0 → 26.8.1 in that same lockfile.

Verified locally against the pinned toolchain before pushing: go tool golangci-lint run exits 0 with no panics, and gofmt -l is clean across the repo.

Bumping go to 1.27 looks worth doing on its own once golangci-lint is upgraded to a release that supports it.

---

Generated by Claude Code

[mikeland73]

The example matrix on 773d8be surfaced six failures across the three project-tests-only shards. Root-caused each from the job logs; fixes are in a3b688e.

Reverted — the new package is broken upstream, nothing this repo can fix:

Example(s)	Bump	Failure
csharp, fsharp	dotnet-sdk 6.0.418 → 8.0.424	libhostfxr.so resolves against the runner's system glibc and needs GLIBC_ABI_GNU2_TLS, which it doesn't export: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_ABI_GNU2_TLS' not found
java/gradle, java/maven	jdk@19 19.0.2+7 → 19-ga	error: Package 'openjdk-19-ga' ... is marked as insecure, refusing to evaluate

Only those two packages went back. gradle 8.6 → 8.14.4, maven 3.9.6 → 3.9.16 and binutils 2.40 → 2.46 are unaffected and stay in those same lockfiles.

Worth noting for a follow-up: jdk@19 is EOL, which is why nixpkgs now flags it. Moving those two examples to a supported JDK would be the durable fix, but that's a change to the examples rather than a lockfile refresh, so I left it alone.

Fixed — the bump was fine, the example needed updating:

• poetry-pyproject-subdir: Poetry 2.x makes No file/folder found for package poetry-pyproject-subdir-service a hard error where 1.7 only warned. This example uses Poetry purely for dependency management and has no service/ package, so it now declares package-mode = false — Poetry's own suggested remedy. poetry-demo has a real package directory and already passes on 2.4.1, so poetry stays at 2.4.1 in both.
• stacks/rails: the Gemfile pinned ruby "4.0.2" exactly, so ruby 4.0.6 failed with Your Ruby version is 4.0.6, but your Gemfile specified 4.0.2. Moved the pin and Gemfile.lock's RUBY VERSION to 4.0.6, keeping the bump.

One caveat on that last one: I wrote ruby 4.0.6p0 into Gemfile.lock, guessing the patchlevel. Bundler's hard check is the Gemfile directive and bin/bundle install rewrites that block on the next run, so it shouldn't matter — but it's the one part of this push I couldn't verify, since this environment can't install the packages to reproduce a run.

Also confirmed green on 773d8be: golangci-lint (ubuntu) after the earlier Go revert, Test Flake Build, all three project-tests-off shards, and every test-nix-versions leg.

---

Generated by Claude Code

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance (no CLAUDE.md files exist in this repo).

• The 3 hand-written changes (Poetry package-mode = false, Rails Gemfile/Gemfile.lock ruby version bump) are correct and internally consistent.
• All changed devbox.lock files are valid, self-consistent JSON with no version/hash/store-path mismatches.
• One candidate issue was investigated and disproven: php@latest bumping 8.3→8.5 while php83Extensions.* stays labeled 8.3 in examples/development/php/latest, examples/stacks/lapp-stack, and examples/stacks/lepp-stack looked like an ABI mismatch, but devbox's PHP plugin rebuilds extensions against whatever interpreter is actually pinned, ignoring the stale php83Extensions attribute name — so no runtime load failure occurs, just a stale label.

🤖 Generated with Claude Code