(My crazy?) Plan to re-unite 0.23 and 1.0

We’ve already made big progress towards this via #5252 and #5241 and will be helped along by #5226 (see also #5044).

My assumptions:

1. Once upon a time, 0.23 and 1.0 were the same, until I completely destroyed 1.0 with Scala.js.
2. Besides JS, the diff between 0.23 and 1.0 at the moment is very small (does anyone have a list?).
3. 0.23 will be merging into 1.0 for years to come.
4. “Platformed” files (split across JVM/JS) are the root of the worst merge conflicts.
5. Most of the file-splitting I did to cross-compile to JS was due to lack of cross-compiling crypto and fs2-io. Both have since been addressed, and all these files can be glued back together.
6. Off the top of my head, the biggest breaking changes actually needed to cleanly cross to JS are:

• Some Async constraints instead of Sync, but only for crypto (and only needed for browsers).
• Using ip4s for the Server address, rather than a JVMism.

What this means (bear with me): we can probably cross-compile 0.23 core, circe, and client for JS (minus crypto support in browsers) with minimal effort i.e. just by fiddling with the build. I’m not saying we should do this, although it would:

• tighten the diff in the build configuration between 0.23 and 1.0;
• force 0.23 feature development to target JS as well, to avoid painful merges into 1.0;
• certainly be nice to have a stable release with JS support.

On the other hand, this would push us even further away from 0.22.

In any case: what I’d like to do (if it’s not too insane) is “re-cut” 1.0 from the updated 0.23. The thinking is, instead of glueing files back together in 1.0, we have a much better chance to quash future merge conflicts by re-copying the affected files directly out of 0.23 (of course, being very careful not to overwrite any of the nice non-JS things added to 1.0 since). The more we can do to make 0.23 like 1.0 the nicer the outcome will be.

Anyway, just a (crazy) idea and understandably the ship may have sailed on some of this. But if it’s still an option there’s some exciting things looming for 1.0-only that once landed will make this more difficult.

Finally, apologies for how time/energy-consuming this JS stuff has been, I really hope things will be smoother from here.

[rossabaker]

I think we can revisit the notion of the MimeDB, given that we’re creating constants for proprietary formats for business that went under a decade ago. The bar to get into that registry wasn’t high. It’s neat that we’re adhering to standards, but rearranging how we adhere to it is definitely on the table.

[armanbilge]

This is probably a terrible idea but what about cross-building 0.23 for scala.js, with the js version not being published and all the js implementations being stubbed out with ????

EDIT: that second suggestion isn’t not going to work, as it still relies on dependencies being available for js.

Actually, that’s what part of what I’m suggesting. The 0.23 dependencies (which are shared with 1.0) are now available for JS. And the amount of JS specific (i.e. non-shared) code in 1.0 is very very small (it’s been moved upstream into fs2.io and http4s-crypto). If you have a look at the JS sources for core you can see it’s mostly just empty files: https://github.com/http4s/http4s/tree/main/core/js/src/main/scala/org/http4s

That’s why I’m pretty sure we’ve arrived to a place where we can “flip the switch” on several 0.23 modules and they should already be publishable for JS (or, very nearly so).

Just a random thought, but is there any reason why splits into platform-specific source files can’t be backported to 0.22/0.23 for subsequent ease of forward merging, even when there’s only a jvm file in those versions?

It could work, the hard part is policing these files in 0.22/0.23 since there’ll be no tests/compiler guidance about what should or shouldn’t be platformed. The better news is that particularly after #5226 merges I think we can get rid of nearly all these split files actually.