`vinext deploy` with a custom `vite.config` fails on missing `cloudflare()` (and the local-vs-deploy wrangler.jsonc story)

[hyf0]

Problem

vinext deploy requires cloudflare() (@cloudflare/vite-plugin) in the Vite config, but when a project has a custom vite.config.ts, vinext deploy doesn't add it and fails:

Created wrangler.jsonc
Created worker/index.ts
Error: [vinext] Missing @cloudflare/vite-plugin in your Vite config.
  ...
  Or delete your Vite config and re-run `vinext deploy` to auto-generate it.

The "delete your Vite config and re-run" suggestion isn't viable for a real port — the custom config carries required resolution/transform settings. So you must hand-add cloudflare() and install @cloudflare/vite-plugin.

Compounding it: @cloudflare/vite-plugin requires a wrangler config to exist, but vinext deploy only generates wrangler.jsonc at deploy time — so adding cloudflare() unconditionally breaks local vinext build/dev (no wrangler.jsonc). You end up either committing wrangler.jsonc or gating the plugin on its presence.

Suggested fix

• When a custom Vite config is present, vinext deploy could inject cloudflare() (and install the dep) automatically, the same way it does when generating the config.
• Document the local-vs-deploy story for cloudflare() + the generated wrangler.jsonc (when to commit it, how to keep local vinext dev/build working).

(Related to the Cloudflare-dashboard deploy friction in #2.)

[hyf0]

🔎 Triage — Next.js behavior vs vinext behavior

Method: grounded in the installed Next.js 15.1.12 source (node_modules/next/dist) and the exact vinext 0.1.8 dist (node_modules/vinext/dist) this issue was filed against; each conclusion independently re-checked by an adversarial second pass. vinext targets the Next.js 16 API surface, so a possible version difference was tested explicitly.

Verdict: 🛠️ tooling / UX gap + by-design limitation · should vinext fix: partial · scope: deploy-tooling · confidence: high

Next.js behavior

Not applicable to Next.js runtime. Real Next.js has no concept of cloudflare() / @cloudflare/vite-plugin / wrangler.jsonc. Next's deploy/build pipeline (next build) is webpack/Turbopack-based and platform-agnostic; Cloudflare integration in Next is handled by separate adapters (e.g. @opennextjs/cloudflare), not by Next core. There is no Next behavior to match here — this is entirely vinext's Cloudflare deploy path. Confirmed nothing Cloudflare/wrangler-specific exists in installed Next source.

_{Evidence: No grep hit for cloudflare/wrangler in node_modules/next/dist (this is a vinext-only deploy concept; Next core has no equivalent) · https://nextjs.org/docs/app/api-reference/cli/next (next build/start has no cloudflare/wrangler plugin concept)}

vinext behavior

vinext deploy auto-generates a full vite.config.ts WITH cloudflare() ONLY when no vite config exists: getFilesToGenerate pushes a generated config gated on if (!info.hasViteConfig) (deploy.js:803), and the generated Pages-Router config includes cloudflare() (deploy.js:609; App Router variant at deploy.js:573). When a vite config DOES exist, deploy does not touch it; it then runs a guard if (info.hasViteConfig && !viteConfigHasCloudflarePlugin(root)) throw new Error(formatMissingCloudflarePluginError(...)) (deploy.js:999). viteConfigHasCloudflarePlugin is a plain substring check for "@cloudflare/vite-plugin" in the config text (deploy.js:680-692). The thrown message's only remediation paths are hand-adding cloudflare() or "Or delete your Vite config and re-run vinext deploy to auto-generate it" (deploy.js:106-109). vinext never injects cloudflare() into an existing config. This is compounded by an init/deploy inconsistency: vinext init writes a vite.config.ts containing only plugins: [vinext()] with NO cloudflare() (init.js:26-33), so an init'd project hits the deploy guard at deploy.js:999 on first deploy. wrangler.jsonc is likewise only generated when absent (if (!info.hasWranglerConfig), deploy.js:790-794); since @cloudflare/vite-plugin needs a wrangler config present, manually adding cloudflare() to keep vinext deploy happy can break local vinext build/dev until wrangler.jsonc exists/committed. The README documents the custom-config + cloudflare() requirement (README.md:276-299) but not the wrangler.jsonc local-vs-deploy story.

_{Evidence: node_modules/vinext/dist/deploy.js:803 (generates config only when !info.hasViteConfig) · node_modules/vinext/dist/deploy.js:999 (guard throws formatMissingCloudflarePluginError when config exists without the plugin) · node_modules/vinext/dist/deploy.js:106-109 ('Or delete your Vite config and re-run' remediation text) · node_modules/vinext/dist/deploy.js:680-692 (viteConfigHasCloudflarePlugin substring check) · node_modules/vinext/dist/deploy.js:609,573 (generated configs include cloudflare()) · node_modules/vinext/dist/deploy.js:788-794 (wrangler.jsonc generated only when !info.hasWranglerConfig) · node_modules/vinext/dist/init.js:26-33 (init generates vite.config.ts with plugins:[vinext()] and NO cloudflare()) · node_modules/vinext/README.md:276-299 (documents custom config + cloudflare() requirement)}

Is it a version difference (vinext → Next 16 vs react.dev → Next 15)?

No. Has nothing to do with Next 15 vs 16. cloudflare()/@cloudflare/vite-plugin/wrangler.jsonc are vinext's Cloudflare-Workers deploy concepts with no analogue in any Next.js version. The behavior is internal to vinext's deploy.js/init.js scaffolding, not a Next API surface that changed between 15.1.12 and 16.

Fix

dist/deploy.js (getFilesToGenerate gate at :803 + guard at :999 + remediation text at :106-109 — could inject cloudflare() into an existing config or at least give a non-destructive remediation); dist/init.js:26-33 (init generates a config without cloudflare(), creating the trap that deploy then can't repair); README.md (document the wrangler.jsonc local-vs-deploy story).

---

_{🤖 Triaged with Claude Code (Opus 4.8) — read-only analysis against installed Next 15.1.12 + vinext 0.1.8 sources, adversarially verified.}

[hyf0]

Follow-up: once you add cloudflare() to satisfy deploy, you can't scope it to deploy-only — it then breaks vinext dev and local vinext build

The flip side of this issue. After adding cloudflare() to the custom vite.config
(as vinext deploy demands), it runs unconditionally, and there's no clean way
to limit it to the deploy build:

• vinext dev 404s every route. @cloudflare/vite-plugin runs the app in
  workerd, which has no fs. A Pages Router getStaticProps that reads content
  from disk (see Pages Router: getStaticProps runs per-request instead of prerendering → fs-backed SSG apps 500 on Cloudflare Workers (needs --prerender-all) #15) therefore throws for every page, and the dev server returns a
  bare 404 (content-length 0) with no error in the log — very hard to diagnose.
  Static assets (/robots.txt) still serve, which makes it look like routing is
  half-working.
• Local vinext build is also affected. With cloudflare() active, vinext build produces a worker-only bundle (✓ 836 modules ... built in 1.29s) instead
  of the normal multi-environment output, and a subsequent --prerender-all
  step fails with No build output found in dist.

There's no good signal to gate the plugin on:

• command === 'build' is too broad — local vinext build (for vinext start
  preview) is also 'build'.
• The only deploy-time env the deploy flow sets is CLOUDFLARE_ENV, and
  withCloudflareEnv only sets it when --env <name> is passed — a default
  vinext deploy leaves it unset, so it can't be relied on.

Net: a project that needs both a working vinext dev / local vinext build and
vinext deploy has no first-class way to express "only apply cloudflare() when
deploying." Options today are all awkward — gate on a hand-rolled env var the user
must remember to set on deploy, keep two config files, or accept that dev/local
build are broken.

Suggestions:

• Have vinext deploy set a stable, always-present env (e.g. VINEXT_DEPLOY=1 or
  always set CLOUDFLARE_ENV, defaulting to production) so a custom config can do
  ...(process.env.VINEXT_DEPLOY ? [cloudflare()] : []) reliably; or
• Inject cloudflare() itself during vinext deploy (the way the no-custom-config
  path already wires Cloudflare) so user configs don't have to include it at all,
  removing the requirement in this issue's title and the dev/build breakage together.

Env: vinext 0.1.8, Vite 8.1, Pages Router.

[hyf0]

Workaround adopted: auto-detect the deploy command from argv

Resolved on our side by gating cloudflare() so it runs only for
vinext deploy, detected from process.argv (deploy runs its Vite build
in-process, so "deploy" is still in argv when vite.config is evaluated), with
an env override for safety:

import {cloudflare} from '@cloudflare/vite-plugin';

// Active only when deploying. `vinext dev` (workerd has no fs → 404s) and local
// `vinext build --prerender-all` (worker bundle → "No build output found in dist")
// must NOT load it. The static "@cloudflare/vite-plugin" grep still matches via
// the import above.
const isCloudflareDeploy =
  process.argv.includes('deploy') || process.env.VINEXT_DEPLOY === '1';

export default defineConfig({
  plugins: [
    vinext(),
    ...(isCloudflareDeploy ? [cloudflare()] : []),
    // …
  ],
});

Result (verified locally):

• vinext build --prerender-all && vinext start → cloudflare auto-off → 809 routes
  prerendered, all routes 200, real content, 0 per-request compilation. A local
  prerendered preview now works.
• vinext dev → runs in Node instead of workerd (still blocked by the separate
  CJS-interop issue in Tracking: vinext dev is unusable for this app — every route 404s (workerd/no-fs) or 500s (dev module-runner can't CJS-interop the per-request MDX compile chain) #16, but no longer a silent workerd 404).
• vinext deploy (incl. --prerender-all) → argv contains deploy → cloudflare
  on → deploy build unchanged.

It works, but relying on argv.includes('deploy') is a heuristic for what should be
first-class. The cleaner fixes remain: either have vinext deploy inject
cloudflare() itself (so user configs never include it — closing this issue), or
expose a stable, always-present deploy-time signal (e.g. always set CLOUDFLARE_ENV
defaulting to production, or a VINEXT_DEPLOY env) so configs can gate reliably
without sniffing argv.