Pages `bun install` by default? Why.
Hi all - I was wondering if it may be worth discussing issues with Cloudflare Pages running
bun install --frozen-lockfile
by default, without the ability to remove it or even modify the command. I've currently got a P1 ticket filed with support, because the majority of our builds just fail, due to timing out issues.
Failed: build exceeded the time limit and was terminated. Refer to https://developers.cloudflare.com/pages/platform/limits/#builds for build limitsThis occurs almost consistently most recently and it begs the question - why is a build command running that the developer has not specified? It's impossible to debug (such as appending the
--verbose
flag) because we have no choice in the matter. This seems like a questionable technical decision?Cloudflare Docs
Limits · Cloudflare Pages docs
Below are limits observed by the Cloudflare Free plan. For more details on removing these limits, refer to the Cloudflare plans page.
21 Replies
And I'm not the only one:
https://community.cloudflare.com/t/bun-install-hangs-on-cloudflare-pages/602581
https://community.cloudflare.com/t/failed-build-exceeded-the-time-limit-and-was-terminated/622536
https://discord.com/channels/595317990191398933/1194762110215917688
https://discord.com/channels/595317990191398933/1210602919062274118
Pages also defaults to Bun
1.0.1
- but there have been many updates since that release relating to the install
command, and a few specifically targeting fixes for issues with bun install --frozen-lockfile
. The most crucial being Bun 1.0.19
https://bun.sh/blog/bun-v1.0.19#fixed-lockfile-had-changes-but-is-frozen-bug
The code path used by --frozen-lockfile to detect whether a lockfile changed sometimes incorrectly reported that the lockfile changed when it didn't. This would cause errors like:
error: lockfile had changes, but is frozen
To fix this, we've changed how we define "frozen". Instead of relying on input from the filesystem which can potentially change for unrelated reasons, we've switched it to using a hash of the package names and their versions sorted alphabetically with their version numbers. We think this is a more reliable approach.
Bun
Bun v1.0.19
Fixes 26 bugs (addressing 92 đź‘Ť reactions). Use @types/bun instead of bun-types. Fixes --frozen-lockfile bug. bcrypt & argon2 packages now work. setTimeout & setInterval get 4x higher throughput. module mocks in bun:test resolve specifiers. Optimized spawnSync() for large stdio on Linux. Bun.peek() gets 90x faster, expect(map1).toEqual(map2) gets...
Set
BUN_VERSION
env var to whatever you want to use for the version
https://developers.cloudflare.com/pages/configuration/language-support-and-tools/#supported-languages-and-toolsYes, I currently set it manually, but have put in a suggestion for a "latest" version: https://discord.com/channels/595317990191398933/920749372256419930/1214197247177400353
But the point of an old Bun still stands, if you're using Node/npm for example.
It has to default to something and at the time they made it they set to 1.0.1. It cant be changed because it can break peoples sites. Cloudflare doesnt break peoples sites.
I don't see the relevance to allowing you to set a "latest" version just as you can with Node on Pages. And the current version of Bun being set as well as the forced usage of
--frozen-lockfile
IS breaking peoples sites. Regardless, there should be no breaking changes in Bun 1.0.x
. There will be in the transition to 1.1 though: https://github.com/oven-sh/bun/issues/8821GitHub
Breaking changes for Bun v1.1 · Issue #8821 · oven-sh/bun
We do plan to make a few, technically breaking changes to Bun v1.1. We will very clearly communicate this as well. #7829 #8544
My comment wasnt in regards to the latest suggestion. It was to the "old bun" comment.
And it wouldnt break peoples sites who have been using bun 1.0.1 for the entire lifetime of their site only people who would be using stuff that doesnt work in 1.0.1. People who use stuff that doesnt work in 1.0.1 should be setting their version
But the
--frozen-lockfile
command has issues (in that it wasn't working correctly in certain scenarios) that were patched in 1.0.19 and also considering the reports are of users having timeouts even using the default Bun version, isn't really a testament to stability and not breaking things. In fact, Between 1.0.1 -> 1.0.30, there have been 13 release fixing bugs with the bun install
command: https://bun.sh/blogFor something that's set and running as default and considering Bun doesn't seem to push out breaking changes in patch releases, it really should be kept up to date.
Just because bun has issues in certain versions doesnt mean its broken for everyone. People who have been using bun 1.0.1 the entire life of their app will continue to have no issues because if it worked the first time it will work again assuming they dont add anything that doesnt work with bun 1.0.1
But is the assumption in this scenario that users will only redeploy an existing site with no changes? Because there's a good chance they may run into the
--frozen-lockfile
bug patched in 1.0.19: https://community.cloudflare.com/t/error-lockfile-had-changes-but-lockfile-is-frozen/582525
https://discord.com/channels/595317990191398933/1182972894003863552/1182972894003863552
Also the issue is that it will work in your local env in 1.0.1 but won't in production on Pages because of the extra flag..The assumption is they dont change versions of the tools they use.
And if the tool is broken...?
Then you set a version using the env var.
As is literally the issue because the user can't change the command that runs by default
So then it's a fundamentally broken feature?
Which is the point of the discussion
It's not really cloudflares fault that bun had a very broken install command 🤷
Who's saying it is? It is their fault they're running a command a user can't change
A default version needs to be set in stone though because what if it breaks a site to update the default version. Cloudflare aviods breaking sites as much as possible.
But there aren't breaking changes in Bun patch releases?
Your point isn't really relevant to this discussion anyway; it's bad DX to run a command that can't be modified, that is broken and fixed in a later release on a product that doesn't push out breaking changes in patch releases.
Vercel auto updates bun in their builds and I suggest Cloudflare do this as well. We frequently ship updates that fix important bugs
Agreed; straight from Cloudflare support:
We have updates from the Pages engineering team:
Given that Bun is relatively new, and is the only tool we've had reports like this on, we are leaning towards this being a Bun issue.
It looks like Bun's v1.0.29 release added reliability improvements to bun install, so I'd suggest you to try that version (or whatever is latest): https://bun.sh/blog/bun-v1.0.29
Additionally, if you would like to customize your bun install command (eg. to remove --frozen-lockfile or add --verbose), you can add the following environment variable to skip the automatic dependency installation:
SKIP_DEPENDENCY_INSTALL=true{}
Which to me implies they either shouldn’t be running bun install —frozen-lockfile
at all - or at least be keeping it up to date, per CS so the user doesn’t have to.Bun
Bun v1.0.29
Fixes 8 bugs. Bun.stringWidth(a) is a ~6,756x faster drop-in replacement for the popular 'string-width' package. bunx checks for updates more frequently. Adds expect().toBeOneOf() in bun:test. Memory leak impacting Prisma is fixed. Shell now supports advanced redirects like '2>&1', '&>'. Reliability improvements to bunx, bun install, WebSocket c...