Add multi-thread support

[lukeed]

Should be behind a CLI flag & should also be an opt-in – not everything is better/faster just because it's spread across more processes.

Having something simple like uvu --parallel is a nice, quick way to determine is it's a good fit for your project.
Similarly, --parallel should optionally accept a number of processes to fork into. This will also be limited by the number of machine cores. Omitting a number defaults to the host's core count (as seen by os.cpus().length).

This will be reserved for a major-version release – whether that's 1.0 or 2.0.
Definitely on the agenda, but it's a nice-to-have for 98% of projects. There are other, more pressing must-have's that much come first.

[OmgImAlexis]

Also maybe a way to mark a test as being able to be done in parallel or not?

[giuseppeg]

@lukeed have you thought about a viable implementation already? Would you be happy with something like this giuseppeg@5974fe5 ?

Atm the cons of that solution is that for non-parallel runs it still spawns a new process. A more elegant solution would involve rewriting the main module (src/index.js) to be multi process friendly (maybe let the parent process control the output, queues should be scoped to each process etc).

[lukeed]

@giuseppeg Nice! I have a working pass at it now, using worker_threads which will require Node 10+ (8.x is current minimum, so it'd be a breaking change).

The idea is mostly the same, except that threads are cheaper to spawn and can set up a worker pool for mega number of test suites.

In addition to the breaking version requirement, I have this marked as "future" because I want to wait and see what other needs/features develop before locking us into a particular setup.

Until proven otherwise, I still don't see this as a "must-have ASAP" feature, and so it's just something to keep in back of our minds while accepting/building other aspects.

[meoyawn]

why go full multi-thread instead of going with simple asynchrony first.
I reckon it'd be much easier to implement, and remain lightweight.
What do you think?

test.concurrent("name", async () => {
})

my use-case: I'm testing the code that talks with Stripe API, and it slows down the entire suite. Would be great to mark them as concurrent