Further purify the JVM/JS cross

Now that I better understand the merging challenges that lie ahead (e.g., #5023), I wanted to sketch out some ideas to further improve things post-cross.

1. Crypto. My proposal: create a new library (would org.http4s like to host?) that provides a Crypto[F] typeclass. Implementations for JVM, Node.js, and browser platforms will be available with a Cats dependency for JVM and CE 3 dependency for JS. Starting from 0.22, re-implement all cryptography with Crypto[F] (its use can be kept internal) and merge this up through 1.0. If executed right, all crypto code will be identical for JVM and JS (i.e., pure cross). Second bird with this stone: remove the copy-pasted Web Crypto facade currently in core.

2. Files: coreJVM already has a dependency on fs2.io. Also add an optional dependency to fs2.io to coreJS. Re-implement StaticFiles and friends using new fs2.io cross-platform file APIs (hopefully we can run this up through 0.23) and un-platform all file-related methods. Critical assumption here (not 100% on this) is that as long as browser-based apps don’t touch these file-related methods, they should be fine without the fs2.io dependency.

3. Miscellany: several of the platformed classes in core are simply to provide convenience methods to convert to/from JVM-only net classes. I say drop these in 1.0, those who really need this can always use the conversions available in ip4s (slightly less convenient).

Following 1, 2, and 3, I think it’s very likely that core can actually become pure again, or nearly so. More importantly, we’ll have scourged platformed classes across several modules that make merges difficult. Thoughts? 😃

[tpolecat]

There is an argument for not creating this library just to keep the dependency set smaller, even though it leads to a lot of duplicated code.

Another dependency (as long as it’s managed by typelevel and we can get it out the door fast when upgrades are needed) isn’t a problem for me (Skunk).

[rossabaker]

Dependencies on a user repo are rough, unless the user has deputized a few other people, with full admin rights. That’s key: tsec is suffering right now because its CI provider rotted, and it can still be published, but it can no longer be published automatically without a fork.

I feel much safer with Typelevel dependencies. Everyone hits busy stretches where they run off and do Haskell for a year (😰 ) or whatever else and declare inbox bankruptcy. But a Typelevel project can always find an admin. I’ve tried to push my libraries (e.g., case-insensitive) and other microdependencies to Typelevel for just that reason. I would strongly recommend spinning off to there if this proceeds.