Optimization: run tests sequentially by default, separate testing in parallel as an option

[gerteck]

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

#2196 (parallel flag introduced during Lerna update)

Tell us about your environment

Win 11

MarkBind version

5.5.3

Describe the bug and the steps to reproduce it

Currently, default behavior is to run tests (through Lerna) in

• markbind-cli
• @markbind/core
• @markbind/vue-components

in parallel.

markbind/package.json

Lines 22 to 23 in 8c9de42

	"test": "npm run lint && lerna run test --stream --parallel",
	"updatetest": "lerna run updatetest --stream --parallel"

While it might increase the performance slightly by running in parallel, I think that we should prioritize clarity of logged success/error messages. I did a mini-test on performance on my local machine (it isn't very powerful).

There was a one second* decrease in time taken. Sometimes, the serial execution runs faster. It could be because of the overhead.

I think that the increase in performance does not outweigh the costs of making the tests parallel - mainly readability of test logs, on the local machine and on GH actions, when running all 3 test projects. Some examples of what I mean:

https://github.com/MarkBind/markbind/actions/runs/13746517217/job/38442074460?pr=2614#step:8:1399

https://github.com/MarkBind/markbind/actions/runs/13746517217/job/38442074460?pr=2614#step:8:399

Test outputs from cli, core and vue-components can become interweaved with each other, making them illegible and possibly making the results less useful. Also harder to follow as a reader.

I think the scale (or lack thereof) of our tests don't necessary justify the usage of parallel tests.

Let's revert to doing the tests sequentially across packages!

Expected behavior

No response

Anything else?

No response

[gerteck]

An additional comment for this issue - running the tests sequentially would make it easier to debug and step through the program as in https://markbind.org/devdocs/devGuide/development/workflow.html#testing

If it is set to be parallel, it could make it harder to use or reason using the default debugging configuration.

[tlylt]

Is the timing comparison done in your local computer or in CI? CI machine may not be as powerful and the difference might be bigger. But anyways I probably agree with your opinion on this. I was quite annoyed that the logs is no longer readable after we turned to parallel testing.

[gerteck]

Is the timing comparison done in your local computer or in CI? CI machine may not be as powerful and the difference might be bigger.

I ran the crude timing comparison on my local computer. I suppose I could easily run it on CI to test it out. I think I raised a few other issues which I believe will massively improve the test efficiency so we can afford to run it sequentially.