> As for mocking, you don’t have to rely on Jest’s inbuilt mocking libraries and you can use the ones you like better.
I was preparing myself to reply “thanks for the kind and receptive response, but…” I’m glad I read further before drawing a conclusion.
> The good news is that we have never been shy about making breaking changes and we are working on cleaning the house and making many legacy components optional, all while bringing the existing community with us.
> If you care more about raw performance and ES module support and less about isolation, check out the jest-light-runner
It looks likely this addresses the problem I was going to raise! I never wanted to use module mocking in the first place, and never did. But Jest at the time I used it didn’t give me an option to opt out of its isolation model and still imposed all of the problems whether I used module mocks or not. I think this (runner which doesn’t support it) is a great thing to provide, and yeah if you’re okay with breaking changes it’s a much more sensible default.
Thank you for not just the kind and receptive response, but also for showing clear direction from problems I raised! I’ll keep tinkering on my test framework as a hobby project because there are already major perf and semantic wins in it. But this definitely makes Jest a more viable day work consideration for me.
Edit to clarify: I agree isolation between tests is crucial, and isolating modules is an important part of that. It’s just… not what Jest is actually doing. It wasn’t when I was using CJS, and it’s much more challenging to mitigate with ESM. Jest very reasonably clears the require cache between tests, but that’s actually breaking isolation when modules have private state initialized on require. If I remember correctly the ESM solution is the same as my naive one: tack a query parameter on when re-importing.
Realistically, the only current viable solution to isolation is worker threads and WASM/NAPI hacks. Hopefully better isolation primitives are coming up through the standards process.
I was preparing myself to reply “thanks for the kind and receptive response, but…” I’m glad I read further before drawing a conclusion.
> The good news is that we have never been shy about making breaking changes and we are working on cleaning the house and making many legacy components optional, all while bringing the existing community with us.
> If you care more about raw performance and ES module support and less about isolation, check out the jest-light-runner
It looks likely this addresses the problem I was going to raise! I never wanted to use module mocking in the first place, and never did. But Jest at the time I used it didn’t give me an option to opt out of its isolation model and still imposed all of the problems whether I used module mocks or not. I think this (runner which doesn’t support it) is a great thing to provide, and yeah if you’re okay with breaking changes it’s a much more sensible default.
Thank you for not just the kind and receptive response, but also for showing clear direction from problems I raised! I’ll keep tinkering on my test framework as a hobby project because there are already major perf and semantic wins in it. But this definitely makes Jest a more viable day work consideration for me.
Edit to clarify: I agree isolation between tests is crucial, and isolating modules is an important part of that. It’s just… not what Jest is actually doing. It wasn’t when I was using CJS, and it’s much more challenging to mitigate with ESM. Jest very reasonably clears the require cache between tests, but that’s actually breaking isolation when modules have private state initialized on require. If I remember correctly the ESM solution is the same as my naive one: tack a query parameter on when re-importing.
Realistically, the only current viable solution to isolation is worker threads and WASM/NAPI hacks. Hopefully better isolation primitives are coming up through the standards process.