Skip to content
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

Open
1 task
frenchy64 opened this issue Apr 23, 2024 · 3 comments
Open
1 task

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

frenchy64 opened this issue Apr 23, 2024 · 3 comments

Comments

@frenchy64
Copy link
Collaborator

frenchy64 commented Apr 23, 2024

  • 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
Copy link
Member

Deraen commented 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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants