Doug Beardsley

Ahhh, I had not noticed this issue. But I agree that it is definitely a problem.

Ordering seems like the most reasonable mapping to me.

I like the sounds of @imalsogreg's second solution. The core problem here is that in a web app with GHCJS you usually will have some version of the following code...

No, I think groundhog-ghcjs would export its own DefaultKey and Key so GHCJS does not need to build groundhog. It might be necessary to create one more package groundhog-types that...

Yes, this does sound a bit heavy. But I think it would create a fantastic user experience. We've used this pattern before back when we were using haste. We ended...

@imalsogreg Doesn't that just shift the problem from DefaultKey to Key?

Yeah, that might work. The reason we used the type family was just because that matched most closely with what groundhog was doing.

I just threw together something that might pass for a minimal compatibility package. What do you think? https://github.com/mightybyte/groundhog-ghcjs

I don't know yet how well it will work. We'll try it in some real projects and see... This solution should be good when all your keys are Int64. If...

You don't even need to do anything conditionally in the cabal file. The frontend cabal file just depends on `groundhog-ghcjs`, while the backend cabal file depends on `groundhog` and `groundhog-th`....