[wrangler] Configure Next.js projects with vinext - #15020
Conversation
🦋 Changeset detectedLatest commit: 3c76945 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| throw new UserError( | ||
| `The Wrangler option ${JSON.stringify(argument)} cannot be forwarded to vinext. Add the equivalent setting to wrangler.jsonc, then run \`wrangler deploy\` again.`, | ||
| { telemetryMessage: "vinext deploy option unsupported" } | ||
| ); | ||
| } |
There was a problem hiding this comment.
🟡 Deploying with any extra command-line option fails outright in Next.js projects set up with the new tooling
Any deploy option other than the worker name or environment is rejected outright (UserError at packages/wrangler/src/deploy/vinext.ts:80-83) instead of being handled, so a normal deploy command with common extra options — or one that explicitly points at a script or assets folder — stops with an error and nothing is deployed.
Impact: Users of these projects can no longer deploy when they pass everyday options such as a script path, an assets directory, or a log level; the deploy aborts with a confusing message.
Delegation path ignores the explicit-target escape hatches that autoconfig respects
packages/wrangler/src/deploy/index.ts:171-181 gates the new delegation only on !pagesToWorkersDelegation && args.autoconfig && !args.config && !args.dryRun. Unlike the autoconfig gate at packages/wrangler/src/deploy/autoconfig.ts:81-89, it does not exclude args.path, args.script or args.assets. So in a directory detected as a vinext project (isVinextProject, packages/wrangler/src/deploy/vinext.ts:89-131), running e.g. wrangler deploy ./some-worker/index.ts, wrangler deploy --assets ./public, or wrangler deploy --log-level debug reaches getVinextDeployArguments, which only tolerates --autoconfig, --name and --env/-e, and throws a UserError for everything else (including the positional path). The previous OpenNext delegation simply forwarded all arguments (packages/wrangler/src/deploy/open-next.ts:26-40), so this is a new hard failure mode.
Prompt for agents
In packages/wrangler/src/deploy/vinext.ts, getVinextDeployArguments() throws a UserError for every argument other than --autoconfig, --name and --env/-e. The delegation call site in packages/wrangler/src/deploy/index.ts only checks !pagesToWorkersDelegation, args.autoconfig, !args.config and !args.dryRun, so it also triggers when the user explicitly targets something else (positional script path, --script, --assets) or passes harmless global flags such as --log-level. In those cases the deploy aborts entirely instead of proceeding, which is a regression relative to the OpenNext delegation which forwarded all arguments. Consider (a) skipping delegation when args.path/args.script/args.assets are set, mirroring the autoconfig gate in packages/wrangler/src/deploy/autoconfig.ts, and (b) either ignoring/forwarding benign global flags (e.g. --log-level, --autoconfig=false) or deciding whether to delegate before parsing so unsupported flags fall back to the normal wrangler deploy path rather than failing.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
On one hand, it makes sense to throw if you pass in an argument you want to deploy with and that argument doesn't exist.
On the other hand, silently failing or ignoring it could lead to unexpected behaviour.
I think it's fine or better even to keep this throwing an error for now.
emily-shen
left a comment
emily-shen
left a comment
There was a problem hiding this comment.
hey just blocking as we are discussing internally how we can do this change without breaking people running autoconfig each time in CI
| options: { skipConfirmations?: boolean } = {} | ||
| ): Promise<{ config: Config; aborted: boolean }> { | ||
| ): Promise<{ config: Config; aborted: boolean; configured: boolean }> { | ||
| let configured = false; |
There was a problem hiding this comment.
Nit pick: A better name for this would be isConfigured
| export function getVinextDeployFromEnv(): boolean { | ||
| return process.env[VINEXT_DEPLOY_ENV] === "true"; | ||
| } | ||
|
|
||
| export async function maybeDelegateToVinextDeployCommand( |
There was a problem hiding this comment.
Nit pick: Can we add some JSDoc descriptions to these functions
| throw new UserError( | ||
| `The Wrangler option ${JSON.stringify(argument)} cannot be forwarded to vinext. Add the equivalent setting to wrangler.jsonc, then run \`wrangler deploy\` again.`, | ||
| { telemetryMessage: "vinext deploy option unsupported" } | ||
| ); | ||
| } |
There was a problem hiding this comment.
On one hand, it makes sense to throw if you pass in an argument you want to deploy with and that argument doesn't exist.
On the other hand, silently failing or ignoring it could lead to unexpected behaviour.
I think it's fine or better even to keep this throwing an error for now.
| } | ||
|
|
||
| const wranglerConfigFile = projectFiles.find((file) => | ||
| /^wrangler\.jsonc?$/.test(file) |
There was a problem hiding this comment.
What about if the user has a wrangler.json or wrangler.toml config?
I'm pretty sure we have a helper to find and load a Wrangler config so that might be better here?
| vi.mocked(getInstalledPackageVersion).mockReturnValue("1.0.0-beta.4"); | ||
| await writeFile( | ||
| "vite.config.ts", | ||
| 'import vinext from "vinext";\nimport { cloudflare } from "@cloudflare/vite-plugin";\nexport default { plugins: [vinext(), cloudflare()] };\n' |
There was a problem hiding this comment.
Nit pick: We have a dedent helper to make creating these templates easier to read
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
4 participants
Related to #14896.
Configure and deploy Next.js 16 projects with vinext instead of OpenNext through Wrangler automatic configuration. The setup uses explicit non-interactive Cloudflare defaults, delegates deployment to
vinext-cloudflare, and preserves support for existing or manually configured OpenNext projects.A picture of a cute animal (not mandatory, but encouraged)
