fix: avoid mutating tinyrainbow default colors in agent mode#10062
Open
teee32 wants to merge 3 commits intovitest-dev:mainfrom
Open
fix: avoid mutating tinyrainbow default colors in agent mode#10062teee32 wants to merge 3 commits intovitest-dev:mainfrom
teee32 wants to merge 3 commits intovitest-dev:mainfrom
Conversation
Vitest disabled colors in agent mode by mutating tinyrainbow's shared default export during CLI and worker startup. That made user code importing tinyrainbow observe identity color formatters, which violates the boundary between Vitest internals and the code under test. This change removes the global mutation path and routes Vitest's internal color consumers through a local wrapper that uses a non-mutating disabled-colors instance only when agent mode is on. A focused config regression covers the user-code boundary while keeping reporter output uncolored in agent mode. Constraint: Only core-code fixes are allowed for this run Constraint: The fix must stay small and avoid public API changes Rejected: Leave disableDefaultColors in place and patch specific call sites | still leaks shared state to user code Rejected: Add a test-only PR without code changes | user explicitly rejected non-core-code submissions Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep internal color policy isolated from shared third-party singletons unless cross-package behavior is explicitly intended Tested: pnpm --filter vitest build Tested: pnpm exec vitest run test/console-color.test.ts -t 'agent' Tested: pnpm exec eslint packages/vitest/src/utils/colors.ts packages/vitest/src/node/cli/cac.ts packages/vitest/src/runtime/workers/init.ts test/config/test/console-color.test.ts test/config/fixtures/console-color-agent-user-code/basic.test.ts test/config/fixtures/console-color-agent-user-code/vitest.config.ts --no-ignore Tested: git diff --check Not-tested: Full monorepo test suite Related: vitest-dev#10046
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
The regression fixture relies on a runtime alias to load tinyrainbow, but the test/config package does not declare tinyrainbow as a direct devDependency. CI typecheck therefore rejects the import even though the fixture is intentionally resolved by Vitest config at runtime. This records that expectation explicitly on the fixture import so the focused regression remains small and the lint job stops failing on the known fixture-only resolution gap. Constraint: The PR must stay narrowly scoped to the vitest-dev#10046 regression Rejected: Add tinyrainbow to test/config devDependencies | widens package metadata for a fixture-only need Rejected: Rework the fixture to avoid tinyrainbow import | would weaken direct coverage of the reported user-code boundary Confidence: high Scope-risk: narrow Reversibility: clean Directive: If fixture resolution should become statically typed later, prefer a package-local declaration over growing runtime-only aliases Tested: pnpm exec eslint test/config/fixtures/console-color-agent-user-code/basic.test.ts --no-ignore Tested: cd test/config && pnpm exec vitest run test/console-color.test.ts -t 'agent keeps tinyrainbow colors enabled in user code' Not-tested: Full monorepo CI rerun after push Related: vitest-dev#10046 Related: vitest-dev#10062 EOF && git push
sheremet-va
requested changes
Apr 4, 2026
Member
sheremet-va
left a comment
sheremet-va
left a comment
There was a problem hiding this comment.
This is AI slop. The issue is bigger - we use tinyrainbow in multiple packages, including expect, pretty-format and utils
The initial fix stopped Vitest from mutating tinyrainbow's shared singleton, but maintainer review correctly pointed out that agent-mode color policy still leaked through other internal packages that import and use tinyrainbow directly. This follow-up routes internal color consumers in utils, expect, pretty-format, browser, UI, and coverage/browser-playwright helpers through detached agent-aware wrappers, while preserving user-space imports of tinyrainbow. The config regression suite now also proves that failed matcher output stays uncolored in agent mode while user code still sees ANSI colors from tinyrainbow. Constraint: Review feedback requires covering shared internal packages, not just packages/vitest Constraint: Avoid introducing a utils <-> pretty-format package cycle Rejected: Keep the fix scoped to packages/vitest | reviewer confirmed the behavior boundary is wider Rejected: Make pretty-format depend on @vitest/utils/colors | would create a package cycle because utils already depends on pretty-format Confidence: high Scope-risk: moderate Reversibility: clean Directive: New internal color consumers should use package-local or shared detached wrappers instead of importing tinyrainbow default state directly in agent-sensitive paths Tested: pnpm build Tested: cd test/config && pnpm exec vitest run test/console-color.test.ts -t 'agent' Tested: pnpm exec eslint packages/utils/src/colors.ts packages/utils/src/diff/index.ts packages/utils/src/diff/normalizeDiffOptions.ts packages/expect/src/types.ts packages/expect/src/jest-matcher-utils.ts packages/expect/src/jest-expect.ts packages/pretty-format/src/index.ts packages/pretty-format/src/colors.ts packages/browser/src/node/index.ts packages/ui/node/index.ts packages/ui/node/reporter.ts packages/coverage-v8/src/provider.ts packages/coverage-istanbul/src/provider.ts packages/browser-playwright/src/playwright.ts packages/vitest/src/utils/colors.ts test/config/test/console-color.test.ts test/config/fixtures/console-color-agent-expect/basic.test.ts test/config/fixtures/console-color-agent-user-code/basic.test.ts --no-ignore Tested: git diff --check Not-tested: Full PR CI after push Related: vitest-dev#10046 Related: vitest-dev#10062 EOF && git push
Author
|
Thanks — you were right that the first pass was too narrow. I pushed a follow-up that routes agent-mode color handling through detached wrappers across the shared internal paths called out in review, including utils / expect / pretty-format, plus the remaining internal tinyrainbow consumers that participate in agent-sensitive output. I also added a regression covering failed matcher output in agent mode while keeping user-imported tinyrainbow colors enabled. |
sheremet-va
added
the
maybe automated
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.
Problem
In agent environments, Vitest disabled colors by mutating
tinyrainbow's shared default export. That leaked into user code running under test, so code importingtinyrainbowcould unexpectedly lose ANSI output.Reproduction / Observation
Issue #10046 reports that agent detection turns
tinyrainbowcolor functions into identity functions for user code. This change adds a regression that runs Vitest in agent mode and verifies user code can still observetinyrainbowcolor output while Vitest reporter output remains uncolored.Root cause
Vitest called
disableDefaultColors()on the sharedtinyrainbowsingleton during CLI and worker startup. Because user code and Vitest resolve the same default export, that mutation escaped Vitest internals.Change
disableDefaultColors()calls from CLI and worker startuppackages/vitest/src/utils/colors.tspackages/vitest/src/**to use that local wrappertinyrainbowWhy this fix
This preserves the existing agent-mode intent for Vitest’s own output, but stops mutating shared library state that user code depends on. It is a narrow internal fix with a direct regression test.
Risk
Low to moderate. The behavior change is limited to how Vitest sources internal colors in agent mode. No public API changes are involved.
Validation
cd vitest/test/config && pnpm exec vitest run test/console-color.test.ts -t 'agent'cd vitest && pnpm --filter vitest buildcd vitest && pnpm exec eslint packages/vitest/src/utils/colors.ts packages/vitest/src/node/cli/cac.ts packages/vitest/src/runtime/workers/init.ts test/config/test/console-color.test.ts test/config/fixtures/console-color-agent-user-code/basic.test.ts test/config/fixtures/console-color-agent-user-code/vitest.config.ts --no-ignorecd vitest && git diff --checkCloses #10046