A Next.js app depends on a webpack plugin that has no Turbopack equivalent, so the team cannot adopt Turbopack builds. As the lead, how do you decide between staying on webpack, replacing the tooling, or splitting the pipeline?

## Frame it as a cost with an expiry date The instinct is to treat this as a binary — Turbopack or webpack — and argue it on taste. It is better framed as: what is the ongoing cost of each option, and how long does that cost hold? The expiry matters because the ground moves. In Next 16 Turbopack is the default and webpack is reached through an opt-out flag. Being on the non-default path means your configuration gets less testing, the bugs you hit are less likely to be shared by others, and future releases optimize for the case you are not in. Staying on webpack is legitimate; staying on webpack *without a review date* is drift. ## Quantify what the switch is worth Before evaluating options, get numbers, because they usually decide it: - **Dev feedback loop.** Measure cold start, first-route compile and edit-to-update on the real application, both ways. Multiply the difference by edits per engineer per day, times headcount. This is where most of the value lives — it is paid every day by every engineer. - **CI build time.** Minutes per build times builds per day. This one converts to money directly and is easy to over-weight; a two-minute CI saving matters far less than two seconds off every edit. - **Recruiting and staleness.** Sitting on a legacy path has a slow cost in upgrade friction that is real but hard to put a number on. Name it as a risk rather than inventing a figure. Then ask the question people skip: **is the plugin's capability actually required?** A surprising share of `webpack()` blocks are historical — re-implementing something Next now handles natively, or serving a workflow nobody uses. Deleting the requirement is the cheapest resolution available and should be tested first. ## The four options and what each costs **Stay on `--webpack`.** Zero migration effort, everything keeps working. You forgo the speed benefit and you accumulate risk on the legacy path. Correct when the plugin is genuinely essential and the measured benefit is modest. Requires a named owner and a per-release re-check, or it silently becomes permanent. **Move the work out of the bundler.** Frequently the strongest answer. A great deal of what webpack plugins do — uploading source maps, emitting a manifest, generating an asset — does not need to happen *inside* the compilation. Made a discrete CI step, it becomes bundler-independent and stops blocking every future toolchain move. Cost is a one-off engineering effort plus owning a small piece of pipeline. **Replace the tool.** If the plugin belongs to a vendor product, check whether that vendor ships a Turbopack-native integration; many have. Cost is a vendor migration and its risk, so this depends on how deep the tool sits in your workflows. **Split the pipeline** — Turbopack for `next dev`, webpack for `next build`. Tempting, because the daily benefit lands and the blocker only exists at build time. The cost is dev/prod parity: you develop against one bundler and ship artifacts from another, so a bundler-specific difference is invisible until production. Acceptable as an explicitly time-boxed bridge with a date attached; corrosive as a permanent state. ## Decide, then write down what changes the decision The deliverable is not the choice, it is the choice plus its trigger. Something like: we stay on webpack builds; the trigger is that vendor shipping a Turbopack integration or our measured CI time crossing a threshold; the platform team owns re-checking at each Next major; if nothing changes in two quarters we move the plugin's work into a CI step instead. That converts a stalled debate into a tracked item and prevents the outcome where nobody can explain, a year later, why the app still passes `--webpack`. ## The failure modes to name Two, and both are common. **Migrating for the speed number alone** — adopting a bundler because a benchmark looked good, then discovering the source maps stopped uploading and a week of incident debugging cost more than the builds saved. And **freezing** — declaring the migration blocked, filing nothing, and rediscovering the problem during a forced upgrade under time pressure. A lead's job here is to make the constraint explicit and give it an owner, not to win the tooling argument.