Support prune in Bun workspaces

[joshunrau]

Which project is this feature idea for?

Turborepo

Describe the feature you'd like to request

Support turbo prune when using bun.

Describe the solution you'd like

Running turbo prune should work with bun the same as with npm.

Describe alternatives you've considered

Not using bun or not using turbo

[nathanhammond]

We're aware of this limitation. Serializing to the binary Bun lockfile format is a non-trivial task and not imminently forthcoming.

For now, if you want to use turbo prune for a Bun project, you can losslessly use it with either yarn or pnpm. We recommend choosing yarn because the node_modules layout is most-similar to Bun and it is more-likely to be compatible with your project.

cd ./path/to/bun/project
bunx @turbo/workspaces@latest convert ./ yarn --skip-install
turbo prune

If you don't want any of the automated changes to be permanent you can then proceed to revert all changes in the repository.

Note that the output pruned repository must use the package manager you select (yarn or pnpm)—it cannot use bun.

[jordanebelanger]

Note that the output pruned repository must use the package manager you select (yarn or pnpm)—it cannot use bun.

Doesn't bun support the yarn lockfile format? Why the need to switch package manager even after converting a bun.lockb to a yarn lockfile?

P.S would love for this issue to get attention, this is the last blocker for us to move over to bun as our package manager.

[chris-olszewski]

Bun supports serializing the bun.lockb to a yarn.lock to make it human readable, but it doesn't support using parsing a yarn.lock or creating a bun.lockb from a yarn.lock.

There's some chatter around bun getting support for using a package-lock.json and that could open a path forward to turbo prune supporting bun.

[wladpaiva]

Bun supports a human readable lock file now
https://bun.sh/guides/install/yarnlock

Maybe an easy fix would be to have an option for turbo to read specific lock files the same way bun does
turbo prune --yarn

[jukkamarttinen]

This would be the best option, if possible.

[thecrabcode]

Is there any update on this guys? We would also like to use Turborepo alongside bun, but this issue is quite important for us. I'd be happy to help in any way I can

[AirP0WeR]

+1 to this problem

[baptisteArno]

YES please 🙏

[XenoWad01]

I am also very interested in this being supported. My team would love to use bun alongside turbo but this is the main bottleneck preventing us from doing so.

[jukkamarttinen]

This would be lot appreciated for us too.

[mtsewrs]

This is the only thing blocking my company from switching to bun

[XenoWad01]

I am unsure if this actually fixed the problem as I didnt have time to test that the lock file works. But what seemed to have worked for me was doing turbo prune --scope=@bookd/bookd-api --docker; exit 0 which basically ignores the error alltogether. Im not sure if it works properly or not but it does generate an out/ folder properly. It does generate an out folder but I suspect it just contains the non pruned version of the lock file. Here is my docker file for reference:

FROM node:20.11.0 AS init


# RUN npm install -g unzip
RUN npm install -g bun

RUN bun upgrade --canary

RUN npm install -g synp
RUN npm install -g turbo@1.12.3


WORKDIR /usr/src/app
COPY . .

RUN turbo prune --scope=@bookd/bookd-api --docker; exit 0

FROM init AS installer

WORKDIR /usr/src/app


COPY --chown=node .gitignore .gitignore
COPY --from=init --chown=node /usr/src/app/out/json/ ./



COPY --from=init --chown=node /usr/src/app/out/full/ ./

RUN rm -rf /usr/src/app/out/
RUN bun install --frozen-lockfile --production
RUN bun run build

ENV PORT=4000

EXPOSE $PORT

WORKDIR /usr/src/app/packages/bookd-api

RUN chown node /usr/src/app/* && chmod 755 /usr/src/app/*

USER node
CMD bun run /usr/src/app/packages/bookd-api/app.ts

(Dont mind the npm stuf it seems bun install -g does not really work inside docker for me because the it doesent seem to add the commands to path inside docker only)

From what I understand the reason for this not being supported is that prune actually generates a new lockfile from the old one with only a certain package's dependencies in it and it cannot currently parse the .lockb format. Bun currently supports installing from lockb (and from package-lock.json if you are on canary as of this moment). Here is the open issue related to it supporting yarn.lock file: oven-sh/bun#6409. As soon as they support installing from a yarn.lock file this should become a non problem because bun install can generate a yarn.lock file with bun install -y or adding [install.lockfile] print = "yarn" to your bunfig.toml file at the root of your project. In theory you could also use https://github.com/imsnif/synp for converting the yarn.lock file to a package-lock.json file. Turbo seems to auto-detect the type of lockfile you have and will whine about you having multiple ones. What could fix this is a argument for turbo or turbo prune to specify the exact lockfile to use (as mentioned here #7456 (comment)). The current workaround proposed by me is that you just delete the lock files you dont need inside docker.

TLDR:

(be on bun canary) => install with bun install -y always or add the [install.lockfile] print = "yarn" to your bunfig.toml file => (inside docker) => install synp => delete .lockb file => convert yarn.lock to package-lock.json with snyp => remove old yarn.lock => you currently have a package-lock.json and if you are on canary you can install from it with bun.

I didnt yet have time to fully test this theory but if someone has time and manages to do so please let me know I would appreciate it alot. Otherwise I will try to come back to you when I properly pull this off ( which will take some time as I am new to docker and devops in general ).

[luksch42]

@XenoWad01 any updates?

[nicholasoxford]

When deploying docker files to Fly.io, using a Turborepo, having the prune command makes life a lot easier. Especially as your monorepo grows in size