with all the vendorization going on isn't there now a problem between transit-java and the vendorized transit-clj? if a newer or older transit-java ends up getting on the classpath that might break things? I mean given how stable the interface is that seems unlikely, yet still possible?

Not different than other lib dependency?

but the other vendorized libs don't have dependencies so they can't have that interaction

but yes, dependency conflicts need to be sorted either way. just that that one may create more confusing errors

@alexmiller working on this bridging thing - is the dynamic extension really necessary

I just typed an alternative that just extends the protocol implementers directly by using the backing interface

this would be conditionally loaded in cljs.analyzer

no, as I said yesterday, I don't think it's necessary

conditional to tools.reader namespace on classpath -> install the bridges to the shaded protocol

the dynamic part only adds something if people have external extensions to the tools.reader protocols, and I did not find a single case of anyone doing that

https://github.com/clojure/clojurescript/pull/178

@alexmiller mind eye-balling this, will do the conditional load later and the *alias-map* stuff

I can look at it at some point today, yeah

merged the bridging - building an artifact for people to test - if that seems ok - then will put together release notes etc.

1.11.50 should be available soon, reports most welcome