I somewhat agree that creating a new package would “fix” this problem but I’m not sure this is actually a good way to fix this problem.
In Clojure or on the server-side in general we don’t care too much about “code bloat”. So including several variants of basically the same namespace isn’t a big deal. We should probably care more but usually we don’t.
In ClojureScript or in the “frontend” in general we care very much about final code size. If nothing forces us to resolve “version conflicts” then you might end up including several versions of the “similar” thing in your final output. If you ever tried deduping a bloated webpack build you know that this isn’t fun and rather tedious. webpack will silently just use multiple different versions of a package and not even tell you unless you dig into the details. Needless to say that most people do not do this and will end up with huge chunks of duplicated code. I’ve seen examples of builds that included 5 different versions of one library and so on. Since webpack also just does this silently the package authors often don’t even notice that they have a dependency conflict in their own code.
So I disagree with Rich’s approach of just creating a separate namespace/package as a viable path forward. It does prevent certain kinds of issues but if you care about code size at all you’ll be forced to upgrade code anyways to remove the “duplication”.
PS: It was my choice to not allow duplicated packages in shadow-cljs. It would be possible to support this but I never want this to happen in my builds so I never added it. The whole handling of version conflicts could certainly be improved as well.
I got a new one 