process.chdir() is not supported in workers (--no-threads doesn't work)

[cyco130]

Describe the bug

When I try to call process.chdir in a test, I get "TypeError: process.chdir() is not supported in workers". From #566 I understand the solution is passing --no-threads but it doesn't seem to work.

Reproduction

https://stackblitz.com/edit/node-ve8ywd?file=package.json

System Info

System:
  OS: Linux 5.4 Linux Mint 20.3 (Una)
  CPU: (8) x64 Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
  Memory: 3.70 GB / 15.52 GB
  Container: Yes
  Shell: 5.0.17 - /bin/bash
Binaries:
  Node: 18.2.0 - /usr/local/bin/node
  Yarn: 1.22.11 - ~/.npm-global/bin/yarn
  npm: 8.5.1 - ~/.npm-global/bin/npm
Browsers:
  Chrome: 102.0.5005.61
  Firefox: 101.0
npmPackages:
  vitest: ^0.13.1 => 0.13.1

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sheremet-va]

--no-threads no longer runs tests in the same thread, so the workaround no longer works, that is true. I don't think there is a workaround at the moment.

Does it work with jest? If so, is it an actual chdir call in jest or mocked one? Maybe we need to provide our own mocked process.

[cyco130]

Thanks for the quick reply!

I haven't tried with jest, I don't have it set up at the moment, I haven't used it in a while :) Mocking won't help in my case because I needed this to run some CI tests, I will just use spawn's cwd option.

It is surprising and confusing though, maybe we should document it more clearly?

[cyco130]

My quick attempt at trying the same with jest didn't work at all. No idea what's wrong. Maybe it doesn't work on StackBlitz?

[sheremet-va]

My quick attempt at trying the same with jest didn't work at all. No idea what's wrong. Maybe it doesn't work on StackBlitz?

I guess stackblitz doesn't support Jest.

It is surprising and confusing though

Why is it confusing? I thought it was a common knowledge that we run tests in worker. I think we can try forward calling chdir inside a worker to the main thread, but that action will be async, so if some code depends on it right afterwards it will fail. So, maybe this is even more confusing 😄

[cyco130]

I tried locally with jest and it works as expected both in ESM and CJS. I can statSync files in the target directory meaning it really does change the directory.

I think we can try forward calling chdir inside a worker to the main thread

I was hoping for an option to run code in the main thread like the old --no-threads. It may be useful since workers may have other incompatibilities.

[sheremet-va]

I was hoping for an option to run code in the main thread

We don't provide this option, so tests won't have access to the same global space as Vitest internals and server.

[cyco130]

It's reasonable. Thanks for your help!

[fyyyyy]

I am converting jest specs to vitest.
I can confirm process.chdir(path) has no issue with jest, but vitest throws an error regardless of --threads=false
We need this option to test something as vue-cli which generates code in a different folder.

[scalvert]

So what's the path forward here? Simply not using process.chdir doesn't seem like a reasonable forward path.

The use case we currently support in many packages is creating a tmp dir or npm package using something like fixturify-project, and use that directory as a fixture for tests. At the end of the test, we dispose of the test directory, which requires us to switch directories before to support OS tests such as windows-latest, which will error if you try to rm a directory when it's the current dir.

This seems like a reasonably common usage, and we were previously using --no-threads with vitest when we needed to support this scenario. Now that --no-threads no longer works for this use case, there doesn't seem to be a workaround.

I understand that this is a larger issue with threads and changing directories, but it seems like we could collectively figure out a solution.

[NullVoxPopuli]

Is there a way to turn of workers for a file?
I'd really like to test all my node utils using chdir :D

[JamesHenry]

Closed my duplicate issue in favour of this one. At the very least this limitation should be called out on the jest migration guide IMO, but obviously it would be even better to have some kind of official path forward on this! Lerna makes extensive use of changing directory in its jest tests that I’d love to use vitest for

[silverwind]

How about an option to use childProcess.fork instead of worker_threads? That's how ava does it.

[jiby-aurum]

@sheremet-va would the core team be willing to accept a PR to add an option that enables to run tests in main thread without going through tinypool.

I was trying to utilise vitest to build a runtime test suite system for an internal project, where I would need the test to run in process so it can access the system in runtime, and this would be a requirement then.

[sheremet-va]

@sheremet-va would the core team be willing to accept a PR to add an option that enables to run tests in main thread without going through tinypool.

I was trying to utilise vitest to build a runtime test suite system for an internal project, where I would need the test to run in process so it can access the system in runtime, and this would be a requirement then.

I already tried it, but communication was really slow: #1790 You can tackle it, if you want.

[koistya]

Q: When Vitest workspaces are used, is there a way to set cwd for each workspace? Otherwise, the root cwd is used instead breaking the tests..

[sheremet-va]

Q: When Vitest workspaces are used, is there a way to set cwd for each workspace? Otherwise, the root cwd is used instead breaking the tests..

@koistya you can mock it in your setup files:

vi.spyOn(process, 'cwd').mockReturnValue('/path/you/want')

Please, next time open a discussion instead of commenting in closes issues.