Clojurians Log v2

That's an easy addition and I don't see any downsides, so yup – sounds good to me, it's happening. :thumbsup:

So @thheller @clojurians.net The stubs approach without such special support is really not great I think. I mean, you can make it work in the cljs case, but remember that this is CLJC, and if both accidentally end up on your classpath, then you have really screwy behavior, since the first one that is found is what gets used. Worse it is super easy to accidentally get both if you pull in a library that accidentally exports one, and another lib that exports the other. This is not a scalable pattern IMO

I realize that the specs themselves end up pulling in clojure.alpha.spec, which has some code that cannot be DCE’d, and that is the bit I think worthwhile to address at the CLJS compiler level.

I think you misunderstand how this works

it is literally impossible for them to conflict

in CLJS I agree, but that is not true on JVM, unless I we are talking abt diff things

or are you talking about the regular stubs? not using :ns-aliases?

I’m talking about using GW in CLJ files

which is JVM

which does not have your feature

I'm only talking about CLJS, this really isn't relevant in CLJ at all since build size is basically a non-factor

so in CLJ it is totally fine to configure this the way you do with guardrails

but in CLJS you CANNOT get rid of the ns requires that your namespace has. so the stub lets you get rid of those cleanly

right, but if you accidentally end up with the stubs on the classpath before the real impl, then it will fail

and it leaves you scratching your head

I’ve had it happen

well my solution with :ns-aliases fixes this ... since there is no secondary package that you are supposed to swap out

2 deps with different maven artifact identities but the same nses will hose you

so you cannot end up with both of them on the classpath

this is a CLJC library

thats exactly the problem my solution fixes

I don’t care about CLJS in this discussion at all

if it breaks my server code, I won’t use it

which this will

shadow-cljs cannot fix a CLJ runtime

I think you missed one important bit here ... there is no extra stubs package.

ah, you’re right

I did miss that

CLJ continues to work like CLJ does.

so you’re saying the stubs will be in the same jar, under a diff name. Got it

:thumbsup:

CLJS continunes to work. you just have the EXTRA option to specify an alias to use. which lets you get rid of that extra bit you might care about.

that’s perfect, actually

sorry to doubt you 🙂

https://github.com/day8/re-frame-debux#option-2-namespace-aliases-with-shadow-cljs

I'm completely with you that a secondary package that contains namespaces of the same name is bad

Just to clarify – I was thinking of adding this in addition to offering the separate stubs package with a special version. Same artifact though.

What I plan to remove is the different artifact – ghostwheel-stubs – with the same namespace.