Skip to content

feat: add bun package manager support#441

Open
natew wants to merge 2 commits intovitejs:mainfrom
natew:feat/bun-support
Open

feat: add bun package manager support#441
natew wants to merge 2 commits intovitejs:mainfrom
natew:feat/bun-support

Conversation

@natew
Copy link
Copy Markdown
Contributor

@natew natew commented Mar 4, 2026

Summary

  • Add bun support to applyPackageOverrides() in utils.ts (bun uses overrides in package.json, same as npm)
  • Add oven-sh/setup-bun@v2 to all CI workflow files so bun is available
  • Fix tests/one.ts to use bunx instead of yarn for playwright install

The one framework (onejs/one) uses bun as its package manager. Previously, applyPackageOverrides would throw unsupported package manager detected: bun since only pnpm, yarn, and npm were handled.

Test plan

  • Run one suite to verify bun overrides are applied correctly and tests pass

- Add bun overrides and install handling in applyPackageOverrides
- Add oven-sh/setup-bun to CI workflows
- Fix one test to use bunx for playwright
utils.ts Outdated
...pkg.overrides,
...overrides,
}
// bun does not allow overriding direct dependencies, force it by updating the blocks themselves
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk if this is true or just opus hallucination

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was - bun overrides do apply to direct deps (unlike npm). removed the comment and the unnecessary direct dep forcing. also moved bun install to beforeInstall per your suggestion so the workflows are untouched now.

- Use npm install -g bun in beforeInstall instead of oven-sh/setup-bun action
- Remove unnecessary direct dep override forcing (bun applies overrides to direct deps)
branch: 'main',
build: ['clean:build', 'build'],
beforeTest: 'yarn playwright install chromium',
beforeInstall: async () => $`npm install -g bun`,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would install bun@latest, it would be better to use the exact bun version set in your packageManager or devEngines field in package.json.

given corepack is entering maintenance and won't be shipped with node in a future release we'll have to move vite-ecosystem-ci away from it at one point so learning how to do the install from npm directly could help.

Idea: read package.json, extract pm+version, run <pm> --version to see if currently installed one is matching version, if not run npm i -g <pm>@version and rerun <pm> --version to confirm.

Copy link
Copy Markdown
Member

@sapphi-red sapphi-red Mar 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm i -g will override the installed bun locally. I'd prefer to avoid that. Can we install it in this repo and use that instead? I guess we need to manage multiple versions as each project may use a different version.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm working on a PoC currently, that only auto-installs if github actions is detected, otherwise tells the user to do it.

but of course this doesn't work for all package managers, yarn doesn't have its latest majors on npm, insetad you have to npm i -g yarn which installs yarn v 1.2.2 and then you have to yarn set version <version you actually want> but it'll complain you have to use corepack if it detects a packageManager field. fml

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the idea with installing it locally is nice too, we'd have to set up a separate directory (maybe inside workspace?) and then manipulate path so that it is prefered. This is problematic during local use too though because while we can control path in scripted calls, users can also try to run commands in workspace from their own terminal (i often do to reproduce things) and that path we cannot access/change, leading to inconsistent results.

Afraid there is no solution that fits CI and local use that doesn't involve moving everything into containers that provide the consistent binaries/environment to 100% replicate things.
Future me might work on this. But for now we need a practical way to have bun matching packageManager to support the one test

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see #443 for a simplistic approach

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that didn't go anywhere either. i'm leaning towards not supporting bun in vite-ecosystem-ci for now.

@dominikg
Copy link
Copy Markdown
Collaborator

proposing to pause automatic runs until we solve this, #449

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants