fix(core): preserve FORCE_COLOR=0 intent for forked child tasks

[comp615]

Note: An alternative to this PR is to wait for the upstream picocolors#100 fix and then remove the FORCE_COLOR=0 workaround in bin/nx.ts entirely. However, picocolors has not had a release or meaningful activity in over two years and appears to be unmaintained, so this fix ensures correct behavior in the meantime.

Current Behavior

When FORCE_COLOR=0 is set (common in CI to suppress ANSI codes), bin/nx.ts deletes it from process.env as a workaround for picocolors#100. However, task-env.ts and task-orchestrator.ts then default the undefined FORCE_COLOR to 'true' for all forked child tasks, re-enabling ANSI colors in every child process.

User sets FORCE_COLOR=0
  → bin/nx.ts deletes FORCE_COLOR, sets NO_COLOR=1
  → task-env.ts sees FORCE_COLOR === undefined → defaults to 'true'
  → child processes receive FORCE_COLOR=true (overrides NO_COLOR)
  → ANSI escape codes in ESLint, TypeScript, Vitest output

Expected Behavior

FORCE_COLOR=0 should propagate to child tasks, resulting in no ANSI escape codes.

Solution

1. bin/nx.ts: Save the original value in NX_ORIGINAL_FORCE_COLOR before deleting
2. task-env.ts: Extract a getForceColorForChild() helper that checks NX_ORIGINAL_FORCE_COLOR when FORCE_COLOR is undefined
3. task-orchestrator.ts: Use the shared helper at both call sites

Impact

This affects any CI environment that sets FORCE_COLOR=0. In our case, ANSI escape codes in ESLint output broke downstream log parsers that use regex to extract lint errors (the ✖ N problems summary line contains invisible ANSI bytes that prevent matching).

Tests

Added 4 unit tests for getForceColorForChild() covering:

• Explicit FORCE_COLOR passthrough
• FORCE_COLOR=0 → deleted → restored via NX_ORIGINAL_FORCE_COLOR
• Default to 'true' when neither is set
• FORCE_COLOR takes precedence over NX_ORIGINAL_FORCE_COLOR

Fixes #35292

🤖 This PR was drafted with the help of AI

[netlify]

👷 Deploy request for nx-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	54d893b

[netlify]

👷 Deploy request for nx-dev pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	54d893b

[comp615]

@FrozenPandaz FYI

Also note that I think it might be OK if force-color true wasn't set in CI

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 54d893b

Command	Status	Duration	Result
nx affected --targets=lint,test,build,e2e,e2e-c...	❌ Failed	41m 50s	View ↗
nx run-many -t check-imports check-lock-files c...	✅ Succeeded	3s	View ↗
nx-cloud record -- pnpm nx-cloud conformance:check	✅ Succeeded	16s	View ↗
nx build workspace-plugin	✅ Succeeded	2m 36s	View ↗
nx-cloud record -- nx sync:check	✅ Succeeded	21s	View ↗
nx-cloud record -- nx format:check	✅ Succeeded	6s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-04-27 21:52:20 UTC

[nx-cloud]

Nx Cloud has identified a possible root cause for your failed CI:

This CI failure appears to be related to the environment or external dependencies rather than your code changes.

No code changes were suggested for this issue.

You can trigger a rerun by pushing an empty commit:

git commit --allow-empty -m "chore: trigger rerun"
git push

View detailed reasoning on Nx Cloud ↗

🔔 Heads up, your workspace has pending recommendations ↗ to auto-apply fixes for similar failures.

_{🎓 Learn more about Self-Healing CI on nx.dev}