Skip to content

build(bun): allow Turbopack bundler flag on Bun 1.4+ with configurable Webpack fallback - #11471

Merged
diegosouzapw merged 1 commit into
diegosouzapw:release/v3.8.51from
TheDemonTuan:build/bun-turbopack
Aug 25, 2026
Merged

build(bun): allow Turbopack bundler flag on Bun 1.4+ with configurable Webpack fallback#11471
diegosouzapw merged 1 commit into
diegosouzapw:release/v3.8.51from
TheDemonTuan:build/bun-turbopack

Conversation

@TheDemonTuan

@TheDemonTuan TheDemonTuan commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Summary

Allows Next.js 16.3 Turbopack build flag on Bun 1.4+ while keeping OMNIROUTE_USE_TURBOPACK=0 as the explicit Webpack fallback.

Context & Motivation

Previously, resolveNextBuildBundlerFlag unconditionally forced --webpack whenever process.versions.bun was true due to historical V8 worker binding mismatches in earlier Bun versions.

With Bun 1.4+ adding extensive Node.js compatibility improvements and officially supporting Next.js 16.3 + Turbopack, this change:

  1. Removes the hardcoded Bun check from resolveNextBuildBundlerFlag so that OMNIROUTE_USE_TURBOPACK=1 (or unset) delegates to --turbopack.
  2. Preserves OMNIROUTE_USE_TURBOPACK=0 as the reliable fallback for --webpack.
  3. Makes Dockerfile.bun support --build-arg OMNIROUTE_USE_TURBOPACK=0 as an escape hatch.

Key Changes

  • scripts/build/build-next-isolated.mjs: resolveNextBuildBundlerFlag evaluates baseEnv.OMNIROUTE_USE_TURBOPACK === "0" to return --webpack, otherwise defaults to --turbopack.
  • Dockerfile.bun: Replaces hardcoded ENV OMNIROUTE_USE_TURBOPACK=0 with ARG OMNIROUTE_USE_TURBOPACK=1 and ENV OMNIROUTE_USE_TURBOPACK=${OMNIROUTE_USE_TURBOPACK}.
  • tests/unit/build/resolve-next-build-bundler-flag.test.mjs: Added unit tests covering default behavior and explicit OMNIROUTE_USE_TURBOPACK=0 fallback.

Validation

  • Tested with node --test tests/unit/build/resolve-next-build-bundler-flag.test.mjs: 3 pass, 0 fail.
  • Tested with bun test tests/unit/build/resolve-next-build-bundler-flag.test.mjs: 3 pass, 0 fail.

@ntdatt812 ntdatt812 mentioned this pull request Aug 25, 2026
Merged
5 tasks done
@diegosouzapw
diegosouzapw merged commit 892f359 into diegosouzapw:release/v3.8.51 Aug 25, 2026
4 of 6 checks passed
diegosouzapw pushed a commit that referenced this pull request Aug 26, 2026
@dependabot
deps: bump the development group across 1 directory with 8 updates (#…
e0ea3f9 
…11428)

Validated in a combined dependabot worktree off release/v3.8.51 tip alongside #11426 and #11440 — a fresh npm install of all three combined (2437 packages, 0 vulnerabilities) plus full-suite validation:
- typecheck:core, file-size, changelog-integrity, complexity, cognitive-complexity, check:cycles — all OK, including through the @types/node 22→26 major jump
- npm run lint — 0 errors (after also draining an unrelated stale-suppressions cascade, see #11596)
- npm run test:vitest — 451/452 pass; the 1 failure (auto/glm materialization) is a pre-existing timing-flaky test, reproduced 11/11 pass ×3 in isolation, unrelated to this bump
- Node runtime unaffected — v24.16.0 unchanged, only the type definitions moved

8 development-group updates. The bun 1.3.14→1.4.0 + @types/bun bump aligns with the Bun-native infrastructure work merged earlier today (#11468/#11470/#11471/#11482), which was built against Bun 1.4+ assumptions.
@rqzbeh rqzbeh mentioned this pull request Aug 26, 2026
Merged
rqzbeh added a commit to rqzbeh/OmniRoute that referenced this pull request Aug 26, 2026
@rqzbeh
fix(docker): bump Bun image to 1.4.0 with Turbopack and port the node…
df2ee1e 
… image's build memory guards

Dockerfile.bun's builder stage has been dying with
`ResourceExhausted: ... cannot allocate memory` on the 16 GB GitHub
runners since the -bun image targets landed (diegosouzapw#11039/diegosouzapw#11168), reding
every "Publish to Docker Hub" run on main and blocking all releases
(diegosouzapw#11709 — latest still points at v3.8.49).

Root causes, both unique to the Bun image path:
- Pinned obsolete oven/bun:1.3.14-slim (2026-05-13) that cannot run
  Turbopack, forcing the memory-hungry webpack production pass, and
  whose bun install fails to resolve playwright@1.62.1 / postcss@^8.5.18
  ("No version matching ... (but package exists)").
- No build memory guards: resolveNextBuildBundlerFlag hard-forces
  --webpack for any process.versions.bun run, and Dockerfile.bun lacks
  the node image's OMNIROUTE_BUILD_WORKERS/CIRCLE_NODE_TOTAL and
  OMNIROUTE_BUILD_MEMORY_MB/NODE_OPTIONS knobs — Next falls back to
  os.cpus()-1 = 3 page-data workers and an 8 GB per-process heap, so
  4+ V8 processes blow past the 16 GB runner and a build worker is
  SIGKILLed.

Fix:
- Bump base image to oven/bun:1.4.0-slim (Turbopack + Node 16.3
  support, dependency-resolution fixes).
- Port diegosouzapw#11471's env-only resolveNextBuildBundlerFlag and Dockerfile.bun
  ARG/ENV OMNIROUTE_USE_TURBOPACK (default 1, webpack escape hatch at
  =0) so the memory-efficient Turbopack path runs on Bun.
- Port the node image's build guards into Dockerfile.bun
  (OMNIROUTE_BUILD_MEMORY_MB=6144 -> NODE_OPTIONS, WORKERS=3 ->
  CIRCLE_NODE_TOTAL), keeping the webpack fallback inside the 12288 MB
  budget.
- Extend tests/unit/docker-build-memory-budget.test.ts to guard both
  images; add tests/unit/build/resolve-next-build-bundler-flag.test.mjs
  (ported from diegosouzapw#11471).

Verified: 9/9 unit tests pass; full builder-stage reproduction
(bun install -> better-sqlite3 rebuild -> bun run build) completes on
the 16-core fleet worker with zero OOM-kills: "▲ Next.js 16.3.1
(Turbopack)", exit 0, 2.2 GB standalone bundle produced.

Closes diegosouzapw#11709.
rqzbeh added a commit to rqzbeh/OmniRoute that referenced this pull request Aug 26, 2026
@rqzbeh
fix(docker): bump Bun image to 1.4.0 with Turbopack and port the node…
f8d7503 
… image's build memory guards

Dockerfile.bun's builder stage has been dying with
`ResourceExhausted: ... cannot allocate memory` on the 16 GB GitHub
runners since the -bun image targets landed (diegosouzapw#11039/diegosouzapw#11168), reding
every "Publish to Docker Hub" run on main and blocking all releases
(diegosouzapw#11709 — latest still points at v3.8.49).

Root causes, both unique to the Bun image path:
- Pinned obsolete oven/bun:1.3.14-slim (2026-05-13) that cannot run
  Turbopack, forcing the memory-hungry webpack production pass, and
  whose bun install fails to resolve playwright@1.62.1 / postcss@^8.5.18
  ("No version matching ... (but package exists)").
- No build memory guards: resolveNextBuildBundlerFlag hard-forces
  --webpack for any process.versions.bun run, and Dockerfile.bun lacks
  the node image's OMNIROUTE_BUILD_WORKERS/CIRCLE_NODE_TOTAL and
  OMNIROUTE_BUILD_MEMORY_MB/NODE_OPTIONS knobs — Next falls back to
  os.cpus()-1 = 3 page-data workers and an 8 GB per-process heap, so
  4+ V8 processes blow past the 16 GB runner and a build worker is
  SIGKILLed.

Fix:
- Bump base image to oven/bun:1.4.0-slim (Turbopack + Node 16.3
  support, dependency-resolution fixes).
- Port diegosouzapw#11471's env-only resolveNextBuildBundlerFlag and Dockerfile.bun
  ARG/ENV OMNIROUTE_USE_TURBOPACK (default 1, webpack escape hatch at
  =0) so the memory-efficient Turbopack path runs on Bun.
- Port the node image's build guards into Dockerfile.bun
  (OMNIROUTE_BUILD_MEMORY_MB=6144 -> NODE_OPTIONS, WORKERS=3 ->
  CIRCLE_NODE_TOTAL), keeping the webpack fallback inside the 12288 MB
  budget.
- Extend tests/unit/docker-build-memory-budget.test.ts to guard both
  images; add tests/unit/build/resolve-next-build-bundler-flag.test.mjs
  (ported from diegosouzapw#11471).

Verified: 9/9 unit tests pass; full builder-stage reproduction
(bun install -> better-sqlite3 rebuild -> bun run build) completes on
the 16-core fleet worker with zero OOM-kills: "▲ Next.js 16.3.1
(Turbopack)", exit 0, 2.2 GB standalone bundle produced.

Closes diegosouzapw#11709.
rqzbeh added a commit to rqzbeh/OmniRoute that referenced this pull request Aug 27, 2026
@rqzbeh
fix(docker): bump Bun image to 1.4.0 with Turbopack and port the node…
e55b6b6 
… image's build memory guards

Dockerfile.bun's builder stage has been dying with
`ResourceExhausted: ... cannot allocate memory` on the 16 GB GitHub
runners since the -bun image targets landed (diegosouzapw#11039/diegosouzapw#11168), reding
every "Publish to Docker Hub" run on main and blocking all releases
(diegosouzapw#11709 — latest still points at v3.8.49).

Root causes, both unique to the Bun image path:
- Pinned obsolete oven/bun:1.3.14-slim (2026-05-13) that cannot run
  Turbopack, forcing the memory-hungry webpack production pass, and
  whose bun install fails to resolve playwright@1.62.1 / postcss@^8.5.18
  ("No version matching ... (but package exists)").
- No build memory guards: resolveNextBuildBundlerFlag hard-forces
  --webpack for any process.versions.bun run, and Dockerfile.bun lacks
  the node image's OMNIROUTE_BUILD_WORKERS/CIRCLE_NODE_TOTAL and
  OMNIROUTE_BUILD_MEMORY_MB/NODE_OPTIONS knobs — Next falls back to
  os.cpus()-1 = 3 page-data workers and an 8 GB per-process heap, so
  4+ V8 processes blow past the 16 GB runner and a build worker is
  SIGKILLed.

Fix:
- Bump base image to oven/bun:1.4.0-slim (Turbopack + Node 16.3
  support, dependency-resolution fixes).
- Port diegosouzapw#11471's env-only resolveNextBuildBundlerFlag and Dockerfile.bun
  ARG/ENV OMNIROUTE_USE_TURBOPACK (default 1, webpack escape hatch at
  =0) so the memory-efficient Turbopack path runs on Bun.
- Port the node image's build guards into Dockerfile.bun
  (OMNIROUTE_BUILD_MEMORY_MB=6144 -> NODE_OPTIONS,
  OMNIROUTE_BUILD_WORKERS=2 -> CIRCLE_NODE_TOTAL = 1 page-data worker),
  keeping the webpack fallback inside the 12288 MB budget.
- Align both images on the measured ~4.5 GB/process RSS budget
  (diegosouzapw#7518/diegosouzapw#11663): OMNIROUTE_BUILD_WORKERS defaults 3 -> 2 (1 page-data
  worker) in Dockerfile and Dockerfile.bun, because the inference model
  (2560 MB/worker) silently accepted a configuration that OOMs the
  runner once real per-process RSS is measured directly.
- Extend tests/unit/docker-build-memory-budget.test.ts to guard both
  images with the measured figure and pin the =2 default; add
  tests/unit/build/resolve-next-build-bundler-flag.test.mjs (ported
  from diegosouzapw#11471); update docs/guides/DOCKER_GUIDE.md.

Verified: 15/15 unit tests pass (measured-budget and =2-pin tests proven
red at =3); full builder-stage reproduction (bun install ->
better-sqlite3 rebuild -> bun run build) completes on the 16-core fleet
worker with zero OOM-kills: "▲ Next.js 16.3.1 (Turbopack)", exit 0,
2.2 GB standalone bundle produced.

Closes diegosouzapw#11709.
@pacocartones pacocartones mentioned this pull request Sep 2, 2026
Merged
4 of 5 tasks
muhamadgalihsaputra pushed a commit to niyatna/NiyatnaRoute that referenced this pull request Sep 27, 2026
@TheDemonTuan
build(bun): allow Turbopack bundler flag on Bun 1.4+ with configurabl…
2dcb4c1 
…e Webpack fallback (diegosouzapw#11471)

Validated in a combined 4-PR batch worktree off release/v3.8.51 tip (last of the Bun-native cluster; conflicted against the already-merged diegosouzapw#11482's Dockerfile.bun hunk in the shared worktree — resolved by taking this PR's configurable ARG/ENV shape, which is exactly what it's designed to replace, and pushed the same resolution to this branch).
- Focused test: resolve-next-build-bundler-flag.test.mjs — 3/3 pass, part of batch's 5/5 node:test run
- typecheck:core, file-size, changelog-integrity, complexity, cognitive-complexity — all OK
- Full-repo lint: 228 pre-existing dashboard react-hooks/* findings, unrelated to this diff

Thanks for validating with both node --test and bun test — good practice given the dual-runtime surface this touches.
muhamadgalihsaputra pushed a commit to niyatna/NiyatnaRoute that referenced this pull request Sep 27, 2026
@dependabot
deps: bump the development group across 1 directory with 8 updates (d…
28c745d 
…iegosouzapw#11428)

Validated in a combined dependabot worktree off release/v3.8.51 tip alongside diegosouzapw#11426 and diegosouzapw#11440 — a fresh npm install of all three combined (2437 packages, 0 vulnerabilities) plus full-suite validation:
- typecheck:core, file-size, changelog-integrity, complexity, cognitive-complexity, check:cycles — all OK, including through the @types/node 22→26 major jump
- npm run lint — 0 errors (after also draining an unrelated stale-suppressions cascade, see diegosouzapw#11596)
- npm run test:vitest — 451/452 pass; the 1 failure (auto/glm materialization) is a pre-existing timing-flaky test, reproduced 11/11 pass ×3 in isolation, unrelated to this bump
- Node runtime unaffected — v24.16.0 unchanged, only the type definitions moved

8 development-group updates. The bun 1.3.14→1.4.0 + @types/bun bump aligns with the Bun-native infrastructure work merged earlier today (diegosouzapw#11468/diegosouzapw#11470/diegosouzapw#11471/diegosouzapw#11482), which was built against Bun 1.4+ assumptions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@diegosouzapw diegosouzapw Awaiting requested review from diegosouzapw diegosouzapw is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@TheDemonTuan @diegosouzapw @hartmark