Bun v1.4.2: a bundler renaming regression whose output ran but computed wrong values

What happened on this date

On 2026-09-05, the Bun team published the v1.4.2 release post; the GitHub release page is timestamped 2026-09-05T05:55Z (UTC). The release mainly fixed regressions introduced in v1.4.1. The build-related one: bun build could rename a nested var to the same name as a let in the same block, so builds importing Elysia failed with a SyntaxError; the same bug could give a let the name of a function parameter or catch binding, producing code that runs but computes wrong values. Other fixes covered an AsyncLocalStorage memory leak, the order of the worker_threads online event, a JavaScriptCore upgrade pulling in about 350 upstream WebKit commits, and a Linux FileSink path that could close a file descriptor twice after a failed epoll registration.

Why it matters for protecting app logic

Identifier renaming is the core operation of minifiers and most JavaScript obfuscators. This regression shows the most dangerous failure shape: not a broken build, but a silent change in semantics while the program keeps running. Teams that add obfuscation, bytecode compilation or single-file executables on top of bundling face similar risks at every layer, and more layers make problems harder to localize. To be precise, the bug affected bun build in Bun 1.4.1, and the notes say nothing about other tools; we cannot infer that any particular obfuscator has the same issue. The real lesson is methodological: protection only has value if the protected program is still correct.

Checks you can run

First, pin exact versions of your bundler, minifier and obfuscator, and land upgrades as separate changes. Second, run tests against the transformed output, not only the source; for critical paths, add differential tests comparing an untransformed build with the release build. Third, pay special attention to scope-sensitive patterns such as block-scoped variables, catch bindings and parameter shadowing, and write cases for them. Fourth, read patch-release notes for your tools and watch for entries labeled as regressions. Fifth, keep a fast path to roll back to the last verified toolchain. Treat any tool upgrade in the build chain as a code change that needs review.

Your checklist

• Pin build and obfuscation tool versions; upgrade in separate changes
• Run behavioral and differential tests on the transformed release output
• Add cases for scope-sensitive patterns such as shadowing