What problem are you trying to solve?
It's hard to keep the version of a tool (like Go or Node) in sync across multiple places in a project: CI configs, Dockerfiles, and devbox.json.
Many teams already store a canonical version string in a file such as .go-version or .node-version so that CI, Docker builds, and local dev tooling can all read from a single source of truth.
Today, devbox.json only accepts a literal version string for a package, so that version has to be duplicated manually in devbox.json as well. This duplication is error-prone — it's easy for devbox.json to drift out of sync with the version file used elsewhere, leading to environments that don't actually match production.
What solution would you like?
Allow the version field for a package in devbox.json to reference a file containing the version string, instead of only a literal version. For example:
{
"packages": {
"go": ".go-version"
}
}
Where dummy/.go-version contains:
When running devbox shell (or any command that triggers environment setup), devbox would detect that the value points to a file, read the version string from that file, and install/use that version — the same as if the version had been written directly in devbox.json. This would let teams maintain a single version file that's shared across CI, Docker, and devbox, removing the need for manual duplication and keeping environments consistently in sync.
Alternatives you've considered
- Manually duplicating the version in
devbox.json and the version file, and relying on CI checks or scripts to verify they match. This works but adds maintenance overhead and is easy to forget.
- A pre-shell hook/script that reads the version file and calls
devbox add/updates devbox.json dynamically before devbox shell runs. This works around the limitation but adds extra tooling and isn't as seamless as native support.
What problem are you trying to solve?
It's hard to keep the version of a tool (like Go or Node) in sync across multiple places in a project: CI configs, Dockerfiles, and
devbox.json.Many teams already store a canonical version string in a file such as
.go-versionor.node-versionso that CI, Docker builds, and local dev tooling can all read from a single source of truth.Today,
devbox.jsononly accepts a literal version string for a package, so that version has to be duplicated manually indevbox.jsonas well. This duplication is error-prone — it's easy fordevbox.jsonto drift out of sync with the version file used elsewhere, leading to environments that don't actually match production.What solution would you like?
Allow the version field for a package in
devbox.jsonto reference a file containing the version string, instead of only a literal version. For example:{ "packages": { "go": ".go-version" } }Where
dummy/.go-versioncontains:When running
devbox shell(or any command that triggers environment setup), devbox would detect that the value points to a file, read the version string from that file, and install/use that version — the same as if the version had been written directly indevbox.json. This would let teams maintain a single version file that's shared across CI, Docker, and devbox, removing the need for manual duplication and keeping environments consistently in sync.Alternatives you've considered
devbox.jsonand the version file, and relying on CI checks or scripts to verify they match. This works but adds maintenance overhead and is easy to forget.devbox add/updatesdevbox.jsondynamically beforedevbox shellruns. This works around the limitation but adds extra tooling and isn't as seamless as native support.