Nicolas DUBIEN

On fast-check side, I think we can consider the problem as closed now that we forward the original error as-is via the official 'Error with cause' mechanism. For the moment,...

Yes, definitely. Let's open a PR. Cases we will have to check before merging anything: - how does it behave when in shrink mode? Side note: _I'm not sure that...

For tests, here is the recipe to run them locally: ```sh # from root of the repo yarn yarn build:all cd packages/fast-check # from packages/fast-check yarn test yarn e2e ```

@xtianjohns The test issue you encountered might be fixed once #3301 gets merged

I haven't seen the way you introduced it in the codebase yet, but a solution could have been to follow the pattern put in place for timeouts. In other words:...

**ava 4.3.3** 🔴  **jasmine 4.4.0** 🔴  **jest 28.1.2** 🔴  **mocha 10.0.0** 🔴  **node 16.14.0** 🟢  **vitest 0.17.0** 🟢 

please deploy

With the new flag against vitest:   Code snippet ```js import { test, expect } from "vitest"; import fc from "fast-check"; fc.configureGlobal({ errorWithCause: true }); test("error cause", () =>...

@jasikpark FYI https://github.com/vitest-dev/vitest/discussions/2212

Closing this issue as the recent merge of https://github.com/dubzzz/fast-check/pull/2965 which makes 'Error with cause' something possible is probably the way to go. Not having to copy the original error within...