Changed Vitest 1.0.0 CLI breaks debugging in IntelliJ / WebStorm

[segrey]

CLI has changed in Vitest 1.0.0-beta resulting in broken Vitest debugging in IntelliJ / WebStorm (WEB-64001), because IntelliJ / WebStorm still passes --threads=false when debugging tests as it did for Vitest 0.x.
Honestly, I don't remember why it passes --threads=false in the first place, because debugging seems to be working without this option.

What would the correct way to start Vitests for debugging? For example, all of the following ways work for me:

• no CLI options
• --poolOptions.threads.singleThread
• --pool forks as suggested in https://vitest.dev/guide/debugging.html#intellij-idea

I'd prefer to not pass any CLI options (i.e. take the 1st way), unless you know some scenarios where it might not work.

Also, it'd be great if you could postpone releasing Vitest 1.0.0 until IntelliJ / WebStorm 2023.3.1 with the fix is released (ETA: late December). Is it possible? Thanks.

[sheremet-va]

Also, it'd be great if you could postpone releasing Vitest 1.0.0 until IntelliJ / WebStorm 2023.3.1 with the fix is released (ETA: late December). Is it possible? Thanks.

No, it is not possible. We made the change to --pool two months ago, this is plenty of time.

What would the correct way to start Vitests for debugging?

--poolOptions.threads.singleThread uses a single Worker to run tests, --pool forks is almost the same as --no-threads, but now it uses several forked processes to run tests. So if the problem is parallelism, this flag will not help. Maybe we can add --debug option to force Vitest to run a single process/thread/whatever it is?

[AriPerkkio]

(b) Detect automatically that the main Vitest process is being debugged and disable parallelism automatically

Just remembered that I actually do use inspector even when multi threading or multi processing is used, when doing performance and memory profiling. Inspector usage is not always about debugger breakpoints.

[segrey]

Agree, profiler also enables inspector. Okay, it won't work easily.
Maybe instead of adding --maxWorkers and --minWorkers it would be more natural to have a boolean flag --disableParallelism or something else like --runInBand in Jest?

[sheremet-va]

We don't really add disable flags, but we can add --no-parallelism that just sets maxWorkers and minWorkers to 1?

[AriPerkkio]

I like --no-parallelism. Let's add that one.

[segrey]

Perfect! Looking forward to --no-parallelism.

[reuel88]

I've read these comments over and over again and still don't understand what's going on. I just want to be able to click the debug icon on the side and have it debug like before. Is there a way to do that?