I do not see FORCE_COLOR being used in the Commander code base.

I do see some odd test failures using Node v18.17.0 on Mac, and in the Jest tests being run automatically in the VSCode editor. I'll add a comment in the linked issue.

I don't think is a problem that needs to be solved in Commander though.

I don't think is a problem that needs to be solved in Commander though.

However, I am glad to know about the issue before stumbling across it myself! 😅

I don't think is a problem that needs to be solved in Commander though.

Was supposed to be a temporary fix, but I guess I will just use npx jest --worker-threads for now. It does seem to run a little faster on my machine, which is also pretty cool.

Force pushed to make merges less cluttered in case the PR does end up considered useful.

If the PR GitHub Checks start failing or other developers trip over this then will do something, but currently passing and hopefully gets fixed in Jest.

For readers, temporary developer work-around to run tests is use npx jest --worker-threads or npx jest --runInBand

• Fix tests (Node.js v18.17.0) #1950 (comment)
• [Bug]: FORCE_COLOR set internally leaks through to tests on Windows after upgrade to Node.js v18.17.0 jestjs/jest#14391 (comment)

I don't like patching the code with detailed work-around for FORCE_COLOR.

But perhaps modifying the Jest call in the run-script to use --worker-threads for now? Has it been well-behaved for you?

(I am currently running at the previous node to avoid the problem!)

But perhaps modifying the Jest call in the run-script to use --worker-threads for now? Has it been well-behaved for you?

For me, it has, but the feature is still experimental, so still not sure it should be relied on in general.

Would be temporary, but good point, no need to use experimental. Tests with --runInBand take 10 s on my computer, which is fine.

Would be temporary, but good point, no need to use experimental. Tests with --runInBand take 10 s on my computer, which is fine.

It's 50 vs 20 seconds on mine 🤨

Closing this in favour of #2011 which has a simpler work-around (with @aweebit added as co-author)

Thank you for your contributions.