vinext build/deploy --env <name> ignores flag, always emits top-level wrangler.json

[evertonresende]

Summary

vinext build --env <name> and vinext deploy --env <name> both ignore the --env flag. The generated dist/server/wrangler.json always reflects the top-level environment from wrangler.jsonc, regardless of which environment is requested. Subsequent wrangler deploy --env <name> then has nothing to override, so it deploys to the default Worker.

This breaks multi-environment workflows (HML/staging/prod) for any project using env.<name> sections in wrangler.jsonc.

Versions

• vinext: 0.0.39
• wrangler: 4.80.0
• node: v25.9.0

Repro

wrangler.jsonc:

{
  "name": "my-app",
  "main": "./worker/index.ts",
  "compatibility_date": "2025-04-01",
  "services": [
    { "binding": "API", "service": "my-api" }
  ],
  "env": {
    "hml": {
      "name": "my-app-hml",
      "services": [
        { "binding": "API", "service": "my-api-hml" }
      ],
      "routes": [
        { "pattern": "hml.example.com", "custom_domain": true }
      ]
    }
  }
}

$ pnpm exec vinext build --env hml
$ python3 -c "import json; w=json.load(open('dist/server/wrangler.json')); print('name:', w['name']); print('services:', w['services']); print('routes:', w.get('routes')); print('definedEnvironments:', w.get('definedEnvironments'))"

Expected output (env.hml applied):

name: my-app-hml
services: [{'binding': 'API', 'service': 'my-api-hml'}]
routes: [{'pattern': 'hml.example.com', 'custom_domain': True}]

Actual output (top-level env, --env ignored):

name: my-app
services: [{'binding': 'API', 'service': 'my-api'}]
routes: None
definedEnvironments: ['hml']

Note: definedEnvironments: ['hml'] shows vinext parsed the env section, but did not apply it.

A subsequent wrangler deploy --env hml against this generated file also ignores --env, since the file has no env key — it deploys my-app (prod) instead of my-app-hml.

Workaround

Patch the generated JSON after build:

pnpm exec vinext build
node -e "
const fs = require('fs');
const p = 'dist/server/wrangler.json';
const w = JSON.parse(fs.readFileSync(p));
Object.assign(w, {
  name: 'my-app-hml',
  services: [{ binding: 'API', service: 'my-api-hml' }],
  routes: [{ pattern: 'hml.example.com', custom_domain: true }],
});
fs.writeFileSync(p, JSON.stringify(w, null, 2));
"
pnpm exec wrangler deploy

Ugly but reliable. Would prefer vinext build --env hml to handle this natively.

Suggested fix

When --env <name> is passed:

1. Read env.<name> from wrangler.jsonc.
2. Deep-merge env.<name> over top-level into the generated dist/server/wrangler.json (with shallow override semantics matching wrangler's own env handling).
3. Or, alternatively, leave the env key intact in the generated file so wrangler deploy --env <name> works downstream.

Related context: cloudflare/workers-sdk#11741 reports a similar --env not respected issue in opennextjs-cloudflare deploy — likely same root cause across CF deployment wrappers.

Impact

Anyone with env.<name> in their wrangler.jsonc (essentially every multi-environment vinext project) is forced to either:

• Maintain duplicate wrangler.jsonc files per env
• Apply manual post-build patches
• Accept that vinext deploy --env <name> silently deploys to the wrong Worker

The "silent wrong Worker" outcome is dangerous — I deployed to prod by accident multiple times before noticing.