fix: an imported @currentEnv must win over the --env fallback - #1050
Merged
Conversation
A directory whose schema gets `@currentEnv` through `@import()` never loaded its own `.env.[env]` files when a fallback env was supplied. `DirectoryDataSource._finishInit()` resolves `currentEnv` before imports are processed, which is too early for an imported `@currentEnv` — so it falls through to `graph.envFlagFallback`. That value is truthy, so the post-import re-check (guarded on `!currentEnv`) never runs, and the directory stays pinned to the fallback env for the rest of the load. There is no fallback in the CLI's default path, so this only shows up when one is set — which the Next.js integration always does, passing `--env development`/`production` from `next dev`/`next build` to match `@next/env`. Its own comment says the user should be able to "ignore it by setting their own `@currentEnv`", and that holds when the decorator is in the same schema; it does not when the schema imports it. In a monorepo where each app's `.env.schema` is just `@import(../../)` of a root schema that owns `@currentEnv=$APP_ENV`, the root's `.env.[APP_ENV]` loads correctly while the app's own is silently skipped in favour of `.env.production` — with no error, and nothing in the loaded-file list to suggest the app file was considered. `_resolveCurrentEnv()` now reports whether the value came from the fallback. A fallback is treated as provisional: it is not acted on before imports, and the post-import re-check runs for it. Deliberately not acted on early, rather than loaded and later overridden — loading `.env.<fallback>` leaves its values in the graph even once the real env is known, so a key present only there would leak into the wrong environment. A resolved `@currentEnv` is still final and still loads before imports, so import conditions can read those values.
Contributor
|
The changes in this PR will be included in the next version bump.
|
Contributor
📦 Bundle size
dist/ only; native binaries are versioned separately and not counted here. |
varlock
@varlock/native-helper-darwin
@varlock/native-helper-linux-arm64
@varlock/native-helper-linux-x64
@varlock/native-helper-win32-x64
commit: |
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes in ea4f7938, covering the fallback-versus-imported-@currentEnv resolution path and its regression coverage.
- Fallback provenance:
_resolveCurrentEnv()now identifies whether an environment came from a real config item or the graph-level fallback. - Deferred fallback loading: fallback-specific files load only after imports have had an opportunity to establish a real
@currentEnv, while direct and inherited@currentEnvvalues still load before import conditions. - Regression coverage: the new test verifies that an imported
@currentEnv=devselects.env.devinstead of astagingfallback. - Release note: the patch changeset describes the corrected imported-
@currentEnvprecedence.
azure/gpt-5.6-sol ｜ 𝕏
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes
@currentEnvarriving via@import()losing to the--envfallback, which made per-app.env.[env]files unusable in the documented monorepo layout under the Next.js integration (it always passes--env development/production).This is @chriscors's original fix from #1036 (commit b012969), cherry-picked as-is so the authorship stays with him. The later revision on that PR was pushed in response to automated review feedback that turned out to be asking for two mutually exclusive behaviors; this original version has the semantics we want.
What this settles
--envis now a true last resort, matching what the CLI help already documents ("ignored if using@currentEnv"):@currentEnv(declared in the schema or inherited from a parent) is final and its.env.[env]files load before imports, unchanged.@currentEnvexists anywhere (including via an import), it wins. Only if none exists does the fallback apply..env.<fallback>values linger in the graph after the real env is known.Deliberate behavior change
Import conditions (
enabled=...) can no longer read values that only exist in.env.<fallback>files, since those files now load after imports. That previously worked only because the fallback resolved early; it never worked when@currentEnvwas real but imported (those env files necessarily load after imports too), so this makes the fallback path consistent rather than privileged. Only affects setups with no@currentEnvat all that gate imports on per-env file values.Supersedes #1036.