jose doesn't build with new js backend

[tysonzero]

Originally brought up this issue in servant-auth which depends on jose: haskell-servant/servant#1764

The actual build failure is in basement which jose transitively depends on via crypton/memory. It's unclear to me whether trying to get basement building directly will be easier or harder than removing the dependency on it, but I can definitely file an issue there too.

@ysangkok pointed out that I should bring it up here, in case it's practical to get jose building with the new backend.

[frasertweedale]

Any "kitchen sink" cryptography library will likely contain cbits or bind to system libs. It is not reasonable to expect them to support the JS backend (as pointed out at haskell-servant/servant#1764 (comment)).

I think if you need to do crypto in JS land, better to bind to whatever JS crypto implementation is appropriate.

If I'm missing something important please let me know! Otherwise, I will close this issue.

[tysonzero]

One thing to consider is if the problem can be deferred to a runtime failure, as I'm fairly sure that other c-dep haskell libraries do still build ok with the js backend, you just generally can't use the functions that call into C unless a corresponding javascript function has been made.

In an ideal world you'd still get the error at compile time if you do actually use one of these functions, but wouldn't get an error if you just needed the types or other safe parts of the module, but it does not appear ghc has much support for that kind of approach.

[frasertweedale]

If there's a way to do it that does not affect the API and is not too time-consuming to implement, I'm open to that. Ideally the crypto library itself could handle that, rather than every consumer.