-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WriteStream.prototype.hasColors()
support
#971
Comments
One more idea. I just checked As a work around I have set |
Would it be possible somehow to use vscode-jest/src/JestProcessManagement/JestProcess.ts Lines 107 to 109 in 9c6f121
Found it by activating
Node and |
@mrazauskas, thanks for your research; it helped a lot! Looks like we could add the I am glad you found a workaround, another one is to use the jest.nodeEnv setting: "jest.nodeEnv": { "COLORTERM": "truecolor" } |
Right, it would be better to add Would it be good idea to add If that sounds good, I could do this after holidays. |
It already is; that is how we pass along the setting The question is if the extension should add it, or leave it to the users as customization when needed. This use case seems to be relatively rare as you are the first user ever bumped into this issue, and I am not sure if there is any ill side-effect if we add it to all use cases... Let's do this: Giving there is an existing setting that you can use, I will not change anything for now. But we will leave this issue open, and if more similar user cases arise, we can certainly reconsider. |
What about mocking jest.spyOn(WriteStream.prototype, "hasColors").mockReturnValue(true); Simple and makes them run in any environment. I think that is better solution than keeping tests dependent on some environmental variables. At first it wasn’t clear why tests are falling, but now I think my tests were simply too fragile and needed a refactor. Thanks for your comments! |
Environment
vscode-jest version
: 5.1.0node -v
: 19.3.0npm -v
oryarn --version
: 3.3.1npm ls jest
ornpm ls react-scripts
(if you haven’t ejected): [email protected]yarn test
(see reproduction repo)Prerequisite
yarn test
Steps to Reproduce
Reproduction repo is here: https://github.com/mrazauskas/x-has-colors
Expected Behavior
Same test result in Jest CLI and
vscode-jest
.Actual Behavior
The snapshot is passing via CLI, but failing via
vscode-jest
.The reproduction is using Node’s build-in
WriteStream.prototype.hasColors()
method (see documentation). Seems likevscode-jest
has some issue with support of this API. I decided to open a ticket, because that is Node’s native API.EDIT: See comment below.
You may notice that Jest is patched in the reproduction repo. The patch makes Jest to use Worker Threads. It has no impact in this case, because there is just one test suite (workers will not ne used).I left the patch just to draw your attention that Jest has similar issue with Node’shasColors()
. When workers are used (Child Process), theenv
is overwritten here: https://github.com/facebook/jest/blob/fd8f89719912996802fe90bdeab1d5a6d8e95d8e/packages/jest-worker/src/workers/ChildProcessWorker.ts#L132-L136As you will see in the codesupports-color
is used there, butsupports-color
does not respect Node’s environmental variablesNODE_DISABLE_COLORS
andNO_COLORS
. In contraryhasColors()
takes those into account. This is why support ofhasColors()
is broken in Jest’s Child Process workers. I can’t find a smart way to fix that, swapping to Worker Threads with a patch was better idea.I was tying to figure out if maybevscode-jest
is doing something unexpected with environment variables as well. Got swamped in the codebase, found nothing relevant. Hopeful all what I wrote here will make it easier to spot the issue for someone familiar with the code (;The text was updated successfully, but these errors were encountered: