yt‑dlp narrows and deprecates Bun support amid security and compatibility concerns

What the announcement says

In issue #16766 of the yt‑dlp repository, maintainer bashonly posted an official notice that Bun support is being limited to a narrow version window (1.2.11 through 1.3.14) and deprecated overall. The key points are:

• The minimum supported Bun version is raised from 1.0.31 to 1.2.11.
• The maximum supported version is capped at 1.3.14, the last release built from the original Zig codebase.
• Versions older than 1.2.0 ignore the ejs lockfile, which the team says is a “significant security concern” given recent supply‑chain attacks on npm.
• The ejs test suite cannot run on Bun < 1.2.11, so older releases cannot be verified.
• Bun’s recent rewrite in Rust, described as “vibe‑coded”, has raised trust issues for the yt‑dlp team.
• The deprecation language means the support window can be closed entirely if maintenance becomes too burdensome.

The notice also references the EJS wiki for supported JavaScript runtimes, though that page has not yet been updated to reflect the new limits.

---

What’s actually new?

A tighter version range

Previously yt‑dlp accepted any Bun version that satisfied the runtime’s >=1.0.31 constraint. The new range (1.2.11–1.3.14) is the result of two concrete technical findings:

1. Lockfile handling bug – Versions prior to 1.2.0 skip the ejs lockfile entirely. The lockfile is the mechanism that pins exact dependency versions, so ignoring it opens the door to malicious supply‑chain modifications.
2. Test‑suite incompatibility – The ejs test harness crashes on Bun < 1.2.11, meaning the developers cannot reliably verify that yt‑dlp works with those releases.

Both issues are reproducible and have been documented in the ejs repository’s CI logs. The fix is simply to require a newer Bun that includes the lockfile logic and passes the test suite.

Deprecation, not immediate removal

The team is not pulling Bun support outright; they are signaling an intent to drop it later if the maintenance cost outweighs the benefit. In practice this means:

• Existing users on a supported Bun version can continue without changes.
• Users on newer Bun releases (e.g., 1.3.15 or later) will receive a warning and will need to either downgrade to a supported binary or switch to Node/Deno.
• The code path for Bun is now guarded by a version check that exits with a clear error message when an unsupported version is detected.

Why the Rust rewrite matters

Bun’s original implementation was written in Zig, a low‑level systems language that the yt‑dlp team trusts because it has a small, auditable codebase. The recent rewrite in Rust was performed with assistance from Claude (the Anthropic LLM), and the commit history shows large sections generated automatically. The maintainers fear that such “vibe‑coded” contributions could introduce hidden supply‑chain risks or obscure bugs that are hard to audit.

---

Limitations and practical impact

Users must manage two runtimes

For developers who already have Bun installed for unrelated projects, the new policy forces an extra step:

• Option 1: Install a separate, pinned Bun binary (e.g., ~/.yt-dlp/bun-1.3.14) and point yt‑dlp at it via --js-runtimes /path/to/bun.
• Option 2: Switch to the default runtimes (Node or Deno). This adds a ~30 MB download for Deno, which some users consider wasteful.

Both approaches are documented in the yt‑dlp README, but the extra friction has already drawn criticism from the community (see comments from Malfrador and Roadhog360).

No guarantee of future compatibility

Because the support is labeled “deprecated”, the code path may be removed in a future yt‑dlp release without further notice. Projects that rely on Bun for reproducible builds should treat this as a breaking change and plan migration now.

Security trade‑offs remain unquantified

While the lockfile bug is concrete, the security implications of the Rust rewrite are more speculative. The team has not published a formal audit of the new Bun codebase, so the claim that it is “potentially unsafe” is based on trust‑model concerns rather than a specific vulnerability.

---

What should developers do?

1. Check your current Bun version – Run bun --version. If it falls outside the 1.2.11‑1.3.14 window, you will need to act.
2. Pin a supported binary – Download a known‑good release from the Bun GitHub releases page and store it locally. Use the --js-runtimes flag to point yt‑dlp at that binary.
3. Consider switching runtimes – Node 20 LTS and Deno 2.3+ are fully supported and receive regular security updates. Switching eliminates the need for a second runtime.
4. Monitor future yt‑dlp releases – The deprecation notice means the next major version could drop Bun entirely. Keep an eye on the changelog.
5. Stay informed about Bun’s security posture – If the Bun team publishes a third‑party audit of the Rust rewrite, re‑evaluate whether the risk is acceptable for your workflow.

---

Wider context

The decision reflects a broader trend in the open‑source tooling ecosystem: projects are tightening runtime dependencies after the 2023–2024 supply‑chain attacks on npm packages. By enforcing a lockfile‑aware runtime and limiting exposure to rapidly evolving runtimes, yt‑dlp aims to keep its own attack surface small.

At the same time, the community reaction highlights a tension between flexibility (supporting many runtimes) and maintainability (focusing on a stable, auditable stack). As more JavaScript runtimes emerge, we can expect similar narrowing of support windows unless the runtimes can demonstrate rigorous security practices.

---

For the full issue discussion, see the original GitHub thread: https://github.com/yt-dlp/yt-dlp/issues/16766