npm init builder.io@latest scaffold is broken on Next.js 16: stale Turbopack detection injects a webpack-only DevTools config

Tracker note: The fix for this does not live in BuilderIO/builder. It belongs to the separately-published create-builder.io and @builder.io/dev-tools packages, neither of which declares a repository or bugs URL on npm (both only list homepage: https://builder.io/). Filing here as the closest public Builder tracker so it isn't lost — please move it if there's a better internal home.

Summary

npm init builder.io@latest → "Next.js" produces a project that cannot start on Next.js 16.

⨯ ERROR: This build is using Turbopack, with a `webpack` config and no `turbopack` config.
   This may be a mistake.

   As of Next.js 16 Turbopack is enabled by default and
   custom webpack configurations may need to be migrated to Turbopack.

This is a hard error, not a warning: next dev never serves a page, and next build fails with Error: Call retries were exceeded. It affects every new user running the quickstart now that create-next-app resolves to Next 16.

Reproduced verbatim against a clean Next.js 16.2.12 scaffold with [email protected] and @builder.io/[email protected].

Root cause

The CLI's Turbopack guard tests for the literal string --turbopack in package.json → scripts.dev. From the published [email protected] bundle:

// Turbopack detection
async function qu(t) {
  let i = await Oi(t, t.getRepoRootDir());
  return i?.scripts?.dev ? i.scripts.dev.includes("--turbopack") : false;
}

// used by the Next.js config injector
if (await qu(t)) return console.warn(
  "Turbopack does not support the Builder.io devtools cli. Please disable Turbopack " +
  "or manually integrate Builder.io into your Next.js project."
), n;

Next.js 15's create-next-app emitted "dev": "next dev --turbopack", so the guard worked. Next.js 16 made Turbopack the default and dropped the flag — the generated script is now plain "dev": "next dev". The check returns false, the guard fails open, and the CLI proceeds to inject BuilderDevTools() from @builder.io/dev-tools/next into next.config.ts.

That plugin adds a webpack-only key unconditionally (node_modules/@builder.io/dev-tools/next/index.mjs, v1.78.0):

export default (opts = {}) => (nextConfig = {}) =>
  Object.assign({}, nextConfig, {
    webpack(config, options) {
      if (opts.enabled !== false) config.plugins.push(new BuilderDevToolsPlugin(opts));
      if (typeof nextConfig.webpack === "function") return nextConfig.webpack(config, options);
      return config;
    },
  });

Next 16 sees a webpack config with no turbopack config → hard error.

Failure chain

flowchart TD
    A["npm init builder.io@latest"] --> B["[email protected]"]
    B --> C["npx create-next-app builder-app<br/>(unpinned → Next 16.2.12)"]
    C --> D["scripts.dev = 'next dev'<br/>NO --turbopack flag"]
    D --> E{"guard: scripts.dev.includes('--turbopack')"}
    E -->|"false — fails open"| F["inject BuilderDevTools() into next.config.ts"]
    F --> G["dev-tools/next adds a 'webpack' key"]
    G --> H["Next 16: webpack config + no turbopack config"]
    H --> I["HARD ERROR — dev and build both fail"]
    E -->|"true (Next 15 only)"| J["warn + skip injection ✅"]

    style I fill:#ffcccc
    style E fill:#ffe4b5

Issue 2 — DevTools is silently dead under Turbopack

The obvious workaround (turbopack: {}) is a trap. Under Turbopack the webpack() hook is never invoked, so BuilderDevToolsPlugin never registers. The error disappears, the app runs, and DevTools is inert with no diagnostic.

Measured on the repro app — served HTML scanned for injected assets:

With turbopack: {}, occurrence counts in the served HTML were dev-tools -> 0, builder -> 0, Builder -> 0. The only devtools hits were Next's own next-devtools chunk.

@builder.io/dev-tools has no Turbopack support at all — its export map is core, figma, figma/jsx-runtime, next, node, remix, remix/server-build, server, vite, webpack, angular. No turbopack entry.

This is what users actually hit in practice: they find turbopack: {} via the error message's own TIP, get a running app, and then report "the DevTools overlay never appears."

Issue 3 — / renders the stock Next.js splash page

Separate from the above, and a real onboarding regression.

The CLI writes app/[...page]/page.tsx — a required catch-all, which does not match zero segments — and never touches app/page.tsx. So the root URL always falls through to the untouched create-next-app homepage. There is no Builder-branded landing page or "Get Started" button anywhere in this flow.

Verified by route probe:

/                   -> catch-all: false | next-splash: true
/some-builder-page  -> catch-all: true  | next-splash: false

The legacy starter used pages/[[...page]].tsx — an optional catch-all, which does match / — so Builder content used to be served at the root. Users following the quickstart reasonably expect a branded landing page and instead get "To get started, edit page.tsx" with zero Builder branding, which reads as a failed install.

For the record, API-key wiring is fine and is not implicated: the CLI writes NEXT_PUBLIC_BUILDER_API_KEY into .env.local (first match of .env.local, .env.development.local, .env.production.local, .env.development, .env.production, .env) and consumes it in the generated builder-page.tsx — gen1 via builder.init(process.env.NEXT_PUBLIC_BUILDER_API_KEY!), gen2 as apiKey on <Content>.

Issue 4 — next build --webpack is separately broken

Even on the --webpack path, production builds fail. The plugin loads ([builder-dev-tools] webpack setupDevTools init) and then throws:

unhandledRejection Error: createDevTools() requires a TypeScript instance passed to the 'ts' option

So --webpack rescues dev but not build.

Proposed fix

1. Fix the Turbopack detection. Gate on the installed Next.js major version, not the --turbopack substring: Next ≥ 16 means Turbopack unless --webpack is explicitly passed. The CLI already ships a version probe it doesn't use here — it spawns npx next -v and parses { major, minor, patch }. Reuse it.
2. Add Turbopack support to @builder.io/dev-tools — the real fix. Until that exists, when Turbopack is detected the CLI should either skip injection (the existing warning path) or write "dev": "next dev --webpack" into package.json alongside the plugin, so the injected config is actually honoured. Silently injecting a no-op webpack plugin is the worst of the three.
3. Fix next build --webpack — pass the TypeScript instance so createDevTools() stops throwing.
4. Pin create-next-app to a known-good major. It is currently invoked unpinned (npx create-next-app builder-app), so the CLI inherits every future Next.js breaking change on the day it ships.
5. Reconsider [...page] vs [[...page]]. The optional catch-all restores Builder content at / and matches the legacy starter, though it would overwrite the create-next-app homepage. At minimum, print a next step telling users which URL to visit.

Underlying anti-pattern

Gating behaviour on a CLI flag string rather than the framework version is what broke here, and it will break again on the next default flip. Worth fixing as a pattern, not just this instance.

Workaround for users today

1. Use "dev": "next dev --webpack" — not turbopack: {} alone, or DevTools stays silently disabled.
2. Visit a non-root path such as /test; / will always show the Next.js splash page.
3. Create a page at that URL in the Builder space matching NEXT_PUBLIC_BUILDER_API_KEY in .env.local.

Environment

Side note for maintainers (recommendation only — no action taken)

While tracing this, packages/create-builder.io in BuilderIO/builder was confirmed to be dead code. It is version 0.1.4, whereas npm serves [email protected] from a different codebase. The published bundle contains zero references to starters/create-builder, BuilderIO/builder, or archive/main.zip, so neither the in-repo CLI nor the starters/ tree is reachable from the public quickstart.

This actively misdirects investigation — packages/create-builder.io and starters/create-builder/nextjs are the first things anyone greps for, and both look plausible while being unreachable. Recommend deprecating or removing them, pending maintainer sign-off.

Also note starters/ is listed in .prettierignore, which causes some tooling to skip that tree entirely; a raw filesystem scan is needed to audit it.

For completeness, no template in BuilderIO/builder has this bug. Only three next.config.* files contain a webpack block and all are pinned below Next 16, so none need a turbopack key: