Repository navigation
Compojure 2.x should be backwards compatible with 1.x #462
Description
- add back
:formatoptions to use ring-middleware-format- consider pulling out muuntaja api-middleware into another function
- Q: if neither
:formatnor:formatsis 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.
- Q: if neither
- consider pulling out muuntaja api-middleware into another function
Activity
Deraen commentedon Apr 24, 2024
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 commentedon Apr 24, 2024
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
apiwas 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 commentedon Jun 7, 2024
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.