> For clarity, we're running a small test on ~2% of new prosumer signups. Existing Pro and Max subscribers aren't affected.

https://x.com/TheAmolAvasare/status/2046724659039932830

What issue did you run into?

Most likely, the developer ran `/loop 10m ` or asked claude to create a cron task that runs every 10 minutes and refreshes & resets git.

In text form:

Bundling 10,000 React components (Linux x64, Hetzner)

  Bundler                    Version                  Time
  ─────────────────────────────────────────────────────────
  Bun                        v1.3.0               269.1 ms
  Rolldown                   v1.0.0-beta.42       494.9 ms
  esbuild                    v0.25.10             571.9 ms
  Farm                       v1.0.5             1,608.0 ms
  Rspack                     v1.5.8             2,137.0 ms

No high-level self updater api is planned right now, but yes for at least the low level parts needed to make a good one

Happy to answer any questions

Nah

I do think the combo of not using Twitter, not using Discord, and not using GitHub does make it a bit more challenging for Zig to become a mainstream programming language. Twitter being the least important amongst those. Hard to say how much it matters in practice, as things tend to win on their strengths and not on lack of weakness

https://github.com/oven-sh/bun/blob/7d5f5ad7728b4ede521906a4...

We trust the self-reported size by gzip up to 64 MB, try to allocate enough space for all the output, then run it through libdeflate.

This is instead of a loop that decompresses it chunk-by-chunk and then extracts it chunk-by-chunk and resizing a big tarball many times over.

https://bun.sh/docs/install/isolated

It’s usually only worth it after ~tens of megabytes, but vast majority of npm packages are much smaller than that. So if you can skip it, it’s better.

- isolated, pnpm-style symlink installs for node_modules

- catalogs

- yarn.lock support (later today)

- bun audit

- bun update —interactive

- bun why helps find why a package is installed

- bun info

- bun pm pkg get

- bun pm version (for bumping)

We will also support pnpm lockfile migration next week. To do that, we’re writing a YAML parser. This will also unlock importing YAML files in JavaScript at runtime.

There is a Windows-only bug in the isolated install mode blocking us from using isolated installs ourselves in the bun repo, and we need to fix that before we can release this.

If you want to try this early, you can run `bun upgrade --canary` and `bun install --linker=isolated` or put `install.linker = "isolated"` in bunfig.toml.

Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral performance impact on macOS and Linux. More importantly, they make using bun install in monorepos a lot more reliable by preventing dependencies from loading versions of other dependencies they did not specify in their own package.json.

Happy to answer any questions about Bun

If you're worried about binary size from features you don't use: the binary size cost of Bun.sql is less than 50 KB (you can check this yourself via the .linker-map file in the *-profile.zip builds of Bun or via https://bloaty-csv-reader.vercel.app which was a tool I wrote a little while ago to see how much space various features of Bun use)

If you're worried about runtime overhead, practically everything in Bun is lazily loaded. So if you never access Bun.sql or Bun.S3Client, it will not load it. And, even if it does load it, because we implement it in native code and worry about this a lot, it doesn't really cost much to load.