Compojure 2.x should be backwards compatible with 1.x

[frenchy64]

• [ ] add back :format options to use ring-middleware-format
  • consider pulling out muuntaja api-middleware into another function
  • Q: if neither :format nor :formats is provided, which do coercion backend do we choose?
    • either need to break 1.x or 2.0.0-alphas
  • could make even more explicit with a keyword option explicitly naming backend
    • still, which to default to?
  • also need a way to set the default for namespaces we don't control via JVM properties
  • coercion defaults have changed with muuntaja. if we silently upgrade 1.x users to muuntaja, we should keep 1.x defaults.

[Deraen]

Can you add the ring-middleware-format support without adding it as a dependency?

In addition to the rmf mw being really slow, even adding the dependencies adds some size to uberjars. Though maybe I fixed that already on rmf 0.7.4 by making Icu4j a optional dependency, that was the biggest library.

Maybe keep the old namespace for use with compojure-1 compatibility, rmf and no muuntaja and then add a new namespace with no rmf and muuntaja? Then as rmf and muuntaja aren't used on the same ns, if an app is only using the new ns, dependencies that are only used on v1 ns can be excluded. This will be a breaking change for projects using v2 now.

[frenchy64]

Yes, if I can't do enough dynaload magic to make rmf optional I will make a new namespace for muuntaja or sequester the rmf stuff in another helper namespace.

I'm hoping to find a solution where v2 has to only change one line, such as explicitly adding a configuration to choose muuntaja. I would release a final 2.x alpha that blows up in this case, then 2.0.0 will default back to rmf.

In that case, the only way to get dependency hell is if you pull in a 2.x alpha api that you don't control. I think that's the best I can do, and is likely good enough.

If api was a macro we could add a JVM property to default per-namespace, but it's not, so we don't know which namespace it occurs in.

[frenchy64]

I'm reconsidering whether I need to add rmf support to 2.x. I figured out how to support 1.x fn? coercions in 2.x, perhaps the remaining differences aren't as important.