Rewriting Test Runner Runtime Architecture
A bit stuck on something, curious if you guys can help me out.
I'm currently (re-)writing a niche-test runner (think jest, vitest, etc) and am struggling a bit with the runtime architecture. So far, I've been providing it as a library, where the runtime is entirely in the hands of the user. E.g. like
Here,
I'd much rather have it be like jest, vitest, where I provide the runtime via a CLI and they just expose their test config, e.g.
And run it via
Not sure how I would approach this. I'm thinking, I could use vite or ts-node programatically, and create some kind of context where I import the users modules in my own runtime.
WDYT?
I'm currently (re-)writing a niche-test runner (think jest, vitest, etc) and am struggling a bit with the runtime architecture. So far, I've been providing it as a library, where the runtime is entirely in the hands of the user. E.g. like
Here,
run is effectively a CLI in user control. They would have to run this, e.g. via tsx my-tests.ts, and provide args, e.g. tsx my-tests.ts --diff (or whatever). That's "simple", but not satisfying.I'd much rather have it be like jest, vitest, where I provide the runtime via a CLI and they just expose their test config, e.g.
And run it via
my-test-runner **/*.foo.bar.ts --diff (or whatever).Not sure how I would approach this. I'm thinking, I could use vite or ts-node programatically, and create some kind of context where I import the users modules in my own runtime.
WDYT?
