[wrangler] Respect CLOUDFLARE_ENV when selecting .env and .dev.vars files - #15022
[wrangler] Respect CLOUDFLARE_ENV when selecting .env and .dev.vars files#15022LeSingh1 wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 9e67844 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 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
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
@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: |
1fc9f12 to
291f6ca
Compare
|
Pushed a correction: the first version applied the The fallback now sits at the two places that actually select the files — the |
…iles `CLOUDFLARE_ENV` is supported as an alternative to `--env`, and the config loader falls back to it via `args.env ?? getCloudflareEnv()`. The `.env` and `.dev.vars` file lookups only consulted `args.env`, so `CLOUDFLARE_ENV=staging wrangler dev` activated the `staging` config environment but still loaded the top-level `.env`/`.dev.vars` files rather than `.env.staging`/`.dev.vars.staging`. Apply the same fallback where those files are selected: at the `getBindings()` call, whose `env` argument is only used to pick `.dev.vars.<env>`, and at `getDefaultEnvFiles()`. `--env` continues to take precedence when both are set. The fallback is deliberately not applied to `StartDevWorkerInput.env`, which also feeds config loading — the config validator distinguishes the two sources to report whether an environment came from `--env/-e` or from `CLOUDFLARE_ENV`, and collapsing them there would misattribute that error.
291f6ca to
9e67844
Compare
|
Rebased onto current Locally: |
2 participants
CLOUDFLARE_ENVis supported as an alternative to--env, and the config loader resolves the active environment asargs.env ?? getCloudflareEnv(). The.envand.dev.varsfile lookups only consultedargs.env, soCLOUDFLARE_ENV=staging wrangler devactivated thestagingconfig environment but still loaded the top-level.env/.dev.varsfiles instead of.env.staging/.dev.vars.staging.Two call sites were affected:
packages/wrangler/src/index.ts—getDefaultEnvFiles(args.env), which populatesprocess.envfor every command.packages/wrangler/src/dev/start-dev.ts—env: args.env, which reaches.dev.vars.<env>/.env.<env>selection viaConfigController→getBindings()→getVarsForDev().Both now use the same
args.env ?? getCloudflareEnv()ordering as the config loader, so--envcontinues to take precedence when both are set. A test covers that precedence explicitly — it passes before and after, as a regression guard.CLOUDFLARE_ENVand with the--envflag's own help text ("Environment to use for operations, and for selecting .env and .dev.vars files"). No documented behaviour changes.Note
This is a contribution from an AI agent: Claude Code (Claude Opus 4.5), working on behalf of @LeSingh1. Review comments will be read and responded to.