Sweet Cinnamon Bun

So with Bun announcing it’s 1.0 release, I simply had to check out the hype. Let’s break down what it would take to migrate is it worth it.

Installation is as simple as “curl -fsSL https://bun.sh/install | bash” and takes only a second, good so far. Our default workflow is to use yarn install which does the job, but for the repo I ran the yarn method on, the install took 56.24s — Not incredible and with the pipelines for this repo taking 10–20mins it’s a not insignificant contribution. How does bun do?

Sweet lord, it’s not even remotely close — bun took only 2.08s. Currently this doesn't seem to have impacted the job itself (2min 14s vs 2min 11s), I assume because we’re not currently using a bun specific docker image and installing it in the job step. However our principal, Jon reported a 53% time reduction on a separate repo, so once adopted, this could have some serious savings.

Doing this required a quick tweak of the gitlab-ci.yaml file to include the install step.

Then additionally the inclusion of a bunfig.toml file, which essentially replaces the npmrc file in the root of the repo

Testing is where the good news seems to end though, as while bun’s test capability seems similarly lightning fast, it requires you to replace your jest mocks with simply ‘mock’ and ‘spyOn’ (No big deal) and rewrite tests to avoid leaning on yet unsupported jest functions like ‘toHaveBeenCalledWith’ (Slightly bigger deal, especially in larger codebases) and small changes like removing ‘await’ from before expect statements and moving ‘jest.timeout’ to a test function parameter.

So what are my takeaways?

For new projects I’d very seriously consider adopting Bun 1.0 from the get go and writing my tests around the gaps. For older projects, I’ll be waiting with bated breath for these features to be supported so I can cut down my test times into something acceptable, I don’t have time for such a rewrite just yet.