feat: better debug support

[sheremet-va]

This PR improves the debugger support by utilizing the new inspector option. Also, a new option was added: vitest.debuggerAddress. With the vitest.debuggerPort, I think we can close #185 now.

Fixes #320
The debugger requires Vitest 1.5.0, but all other features work as they did with 1.4.0

[ffMathy]

Would introducing some kind of state machine pattern help? I feel like it's one of those problems that could be solved by this.

[sheremet-va]

Would introducing some kind of state machine pattern help?

Can you be more specific?

[ffMathy]

Well, let's say that when pressing a particular button (like "start") has different effects in different states.

Maybe when we are in the ContinuousRun state, that button does something else than when we are in another state.

We can represent each state as a class implementing a particular interface with various inputs (onStartClicked) etc, and also allowing each state to control what other states are allowed to be switched to and from.

It's similar to the strategy pattern in a way. I don't know the specifics of the problem, but it sounds like you're describing complex flows that apply differently in particular states.

Can you describe the flows more detailed? Then I can come up with something probably.

Alternatively, for me, it helps drawing it as a state machine on a piece of paper.

[ffMathy]

More info: https://en.m.wikipedia.org/wiki/UML_state_machine

[ffMathy]

And the pattern (you can create variants of it though): https://refactoring.guru/design-patterns/state

[sheremet-va]

We can represent each state as a class implementing a particular interface with various inputs

I see what you mean now, but the problem here is not that we can't organize it, but that it's not possible to do several things at once - for example, you can't debug a test and collect other test files at the same time because Vitest only supports a single pool (it blocks other test runs until the current one is completed).

[ffMathy]

Then each state class can have a property called "canDebug" etc, to represent that.

[sheremet-va]

Then each state class can have a property called "canDebug" etc, to represent that.

Again, this has nothing to do with the code architecture. We need to be able to collect tests despite the debugging, single Vitest instance just doesn't allow that.

[ffMathy]

Ah I see. My bad.

[ffMathy]

Beautiful. Great work! Minor optional suggestions and preferences.