fix(plan): move FORCE_COLOR fallback after pattern filtering#379
Merged
Conversation
Previously FORCE_COLOR was pre-inserted into all_envs before pattern filtering and kept in DEFAULT_UNTRACKED_ENV, which unconditionally overwrote any parent or user-provided value. Move the insert to a post-resolution entry().or_insert() fallback and drop FORCE_COLOR from DEFAULT_UNTRACKED_ENV. The default path (no user config) is unchanged - the child still sees FORCE_COLOR=1 - but users opting in via env / untrackedEnv now get their parent's value passed through, providing an escape hatch for tools that need FORCE_COLOR=0. https://claude.ai/code/session_01JZDXjffYu9W5qykGdmkUXD
branchseer
changed the title
branchseer
added a commit
to voidzero-dev/vite-plus
that referenced
this pull request
May 13, 2026
Bumps the vite-task git dependency from `88bacaa` to `c63db22`. ## Notable upstream changes - feat(cache): add `output` globs for cache restoration ([vite-task#375](voidzero-dev/vite-task#375)) - feat(cache): store colored task logs, strip at display when needed ([vite-task#378](voidzero-dev/vite-task#378)) - fix(plan): move FORCE_COLOR fallback after pattern filtering ([vite-task#379](voidzero-dev/vite-task#379)) - fix: preserve `PATHEXT` for Windows cached tasks ([vite-task#366](voidzero-dev/vite-task#366)) ## Vite+ side changes - Added the new `output: None` field to all `EnabledCacheConfig` initializers in `packages/cli/binding/src/cli/{handler,resolver}.rs` to match the new field added in vite-task#375. - Bumped `rusqlite` to `0.39.0` to match vite-task's new requirement and resolve a `libsqlite3-sys` links conflict. - Regenerated `packages/cli/src/run-config.ts` types snapshot (vite-task task map type tightened). - Removed the `pass-no-color-env` snap test, which is no longer relevant now that `NO_COLOR` is not in vite-task's default env passthrough. - Updated `docs/config/run.md`: - Added an `output` cache config section. - Refreshed the default-passthrough terminal env vars list (only `FORCE_COLOR` is auto-passed; other color vars need opt-in). Compare: voidzero-dev/vite-task@88bacaa...c63db22#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4ed --------- Co-authored-by: Claude <noreply@anthropic.com>
otnc
pushed a commit
to otnc/viteplus-ja
that referenced
this pull request
May 13, 2026
Bumps the vite-task git dependency from `88bacaa` to `c63db22`. ## Notable upstream changes - feat(cache): add `output` globs for cache restoration ([vite-task#375](voidzero-dev/vite-task#375)) - feat(cache): store colored task logs, strip at display when needed ([vite-task#378](voidzero-dev/vite-task#378)) - fix(plan): move FORCE_COLOR fallback after pattern filtering ([vite-task#379](voidzero-dev/vite-task#379)) - fix: preserve `PATHEXT` for Windows cached tasks ([vite-task#366](voidzero-dev/vite-task#366)) ## Vite+ side changes - Added the new `output: None` field to all `EnabledCacheConfig` initializers in `packages/cli/binding/src/cli/{handler,resolver}.rs` to match the new field added in vite-task#375. - Bumped `rusqlite` to `0.39.0` to match vite-task's new requirement and resolve a `libsqlite3-sys` links conflict. - Regenerated `packages/cli/src/run-config.ts` types snapshot (vite-task task map type tightened). - Removed the `pass-no-color-env` snap test, which is no longer relevant now that `NO_COLOR` is not in vite-task's default env passthrough. - Updated `docs/config/run.md`: - Added an `output` cache config section. - Refreshed the default-passthrough terminal env vars list (only `FORCE_COLOR` is auto-passed; other color vars need opt-in). Compare: voidzero-dev/vite-task@88bacaa...c63db22#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4ed --------- Co-authored-by: Claude <noreply@anthropic.com>
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.
Motivation
The change respects the principle that cached output should always be colored by default (for consistency), while allowing users who need different behavior (e.g.,
FORCE_COLOR=0for tools that misbehave with ANSI codes) to opt in explicitly via their task configuration.Summary
Changes how
FORCE_COLORis handled during environment variable resolution. Instead of pre-injectingFORCE_COLOR=1before pattern filtering (which forced it through regardless of user intent), the fallback is now applied after pattern filtering. This allows users to opt in to passing through their ownFORCE_COLORvalue via task config while still defaulting to colored output when not explicitly configured.Key Changes
FORCE_COLOR=1is now inserted after pattern filtering usingentry().or_insert_with(), so it only applies when the user hasn't opted in to passing the variable throughFORCE_COLORis no longer in the default untracked env list, giving users explicit control viaenvoruntrackedEnvconfigtest_force_color_defaults_to_one_when_user_does_not_opt_in— validates fallback when user doesn't listFORCE_COLORtest_force_color_defaults_to_one_when_absent_from_parent— validates fallback when parent env has noFORCE_COLORtest_force_color_passthrough_when_user_opts_in_via_untracked— validates parent value passes through when listed inuntrackedEnvtest_force_color_passthrough_when_user_opts_in_via_fingerprinted— validates parent value passes through and is fingerprinted when listed inenvtest_force_color_fallback_fingerprinted_when_opted_in_but_parent_absent— validates fallback is recorded in fingerprint when user opts in but parent has no valueenvs.rsandconfig/mod.rsclarify the new opt-in model and that users can overrideFORCE_COLORby listing it in task confighttps://claude.ai/code/session_01JZDXjffYu9W5qykGdmkUXD