Simon Hengel

This is something I would love to see as well. From what I understand, the code that extracts the definitions is here: https://github.com/hedgehogqa/haskell-hedgehog/blob/master/hedgehog/src/Hedgehog/Internal/Discovery.hs#L44 If we don't want to reimplement all...

Draft PR: https://github.com/parsonsmatt/hspec-hedgehog/pull/29

1. We should consider adding a CI job for the JS backend. 2. If you can provide a minimal example with exact steps to reproduce the issue, I’d be happy...

Are you implying that the current situation was intended? That this is not a major screw up or oversight? `ghc` depends on `filepath`. Is there a way to depend on...

> `ghc` depends on `filepath`. Is there a way to depend on both `ghc-9.8.2` and import `System.OsString` without ignoring deprecation warnings? Sorry, maybe I was too brief here. I'll spell...

Apparently, `template-haskell` vendors `filepath` by now.

You are maintaining `filepath` though. And it would be easy to avoid this friction, e.g. not adding the deprecation message in the first place, re-exposing from `os-string`, you name it....

> > e.g. not adding the deprecation message in the first place > > How is that an option? No deprecation warning is not an improvement. It's still better than...

I think it's currently not easy to address this. https://gitlab.haskell.org/ghc/ghc/-/issues/25952

That's definitely a bug, either in Hspec or in QuickCheck, not sure. If you want to investigate further, this is the relevant code in Hspec: https://github.com/hspec/hspec/blob/9db7aacb85443fefdbcb078e09df3b7bbf380d2c/hspec-core/src/Test/Hspec/Core/QuickCheck/Util.hs#L46-L54 - [ ] Figure...