-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compojure 2.x should be backwards compatible with 1.x #462
Comments
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. |
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 |
I'm reconsidering whether I need to add rmf support to 2.x. I figured out how to support 1.x |
:format
options to use ring-middleware-format:format
nor:formats
is provided, which do coercion backend do we choose?The text was updated successfully, but these errors were encountered: