Open parsonsmatt opened 1 year ago
A migration guide would be great!
This was a long time ago, but IIRC...
It struck me as problematic that myself and the author of bugsnag-hs
would both be maintaining Haskell types to mirror the Bugsnag API. It's a large API, why would we duplicate this effort? bugsnag-hs
had had more coverage, I think it was 100%, and my own types were not. So I decided to just use it and stop maintaining anything of my own. This seemed strictly better (due to the more coverage) except for the un-prefixing of names, which didn't bother me. Is that all you mean by "nicer, more user-friendly API", that the types were prefixed, or is there more to it?
The split in -wai
and -yesod
was simply to avoid a heavy dependency foot-print for users of Bugsnag in a non-web context (we have a Background Jobs service that uses it, for example).
I understand the desire to avoid work and rely on another API. I just wish they'd stopped instead of you ;)
bugsnag-haskell
had exposed constructors, allowing for RecordWildCards
and a generally easier time with construction/extracting data. That's another difference.
I'll have more to say when I'm farther along, I'm sure
(nvm, will make another issue)
I was unable to find any migration guide for
bugsnag-haskell
tobugsnag
andbugsnag-hs
. I'm planning on writing one up.As I'm starting the migration process, I can't help but feel like it's a downgrade.
bugsnag-haskell
seemed to have a nicer, more user-friendly API. Why the switch?