25 days ago
My last build (3 days ago) installed a correct/updated version of Bun:
╭─────────────────╮
│ Railpack 0.23.0 │
╰─────────────────╯
↳ Detected Node
↳ Using bun package manager
↳ Bun runtime detected
Packages
──────────
node │ 22.22.2 │ railpack default (22)
bun │ 1.3.13 │ package.json > engines > bun (>=1.3.12)```
But today, it no longer does:
╭─────────────────╮
│ Railpack 0.23.0 │
╰─────────────────╯
↳ Detected Node
↳ Using bun package manager
↳ Bun runtime detected
Packages
──────────
node │ 22.22.2 │ railpack default (22)
bun │ 1.0.10 │ package.json > engines > bun (>=1.3.12)```
I noticed when I removed the range operator (">=") from the specification, Railpack installed the correct Bun version:
╭─────────────────╮
│ Railpack 0.23.0 │
╰─────────────────╯
↳ Detected Node
↳ Using bun package manager
↳ Bun runtime detected
Packages
──────────
node │ 22.22.2 │ railpack default (22)
bun │ 1.3.12 │ package.json > engines > bun (1.3.12)```
Did Railpack stop respecting range operators in the engines field?11 Replies
25 days ago
@iloveitaly - Mayhaps you know what is up with this?
25 days ago
Is this still happening for you? Try again and let us know here
We're suspecting an issue related to GitHub packages failures
25 days ago
I'm also experiencing this. Bun version yesterday was: 1.3.13 and now 1.0.10
similar issue for pnpm: https://discord.com/channels/713503345364697088/1498477736098926683
25 days ago
happend to me for pnpm too, still not fixed...
Still happening and appears to be worse.
With:
"bun": ">=1.3.12"
}```
Build fails, logs:╭─────────────────╮
│ Railpack 0.23.0 │
╰─────────────────╯
──────────
node │ 22.22.2 │ railpack default (22)```
Doesn't even recognize or install bun.
25 days ago
also happening to our deploys. could this be a stale mise packages cache?
25 days ago
We're also running into this issue with new builds. Getting lockfile issues on some development services. Fix for those running into this issue, create a mise.toml file with:
[tools]
bun = "1.3.10"
node = "22"
Not a long term fix but if you need to deploy something now it works
25 days ago
another work around is pinning & adding RAILPACK_BUN_VERSION as a variable
@Ray Is this something I need to re-check on my own or live with the workarounds or will we be receiving an update?
21 days ago
Could you try without the workaround now? The core issue here is that GitHub package registry is very flakey - when we fail to download or resolve the latest version, we default to a fallback version instead of trying to fetch the latest from GitHub.
We could look into bumping the default version.