So I didn’t need analyzer…that was cruft I accidentally copied in from ghostwheel. Looks like I can get guardrails almost completely out of a production build. Working on a release to update Fulcro…testing now.

If you have a moment @thheller, force in version 0.0.9-SNAPSHOT of guardrails and remove your file. That should eliminate the need for analyzer, and also shrink the guardrails overhead to nearly nothing (I get 5.5k on a react native build, but I suspect there is something more DCE could do that I’m missing)

ah, I was using simple optimizations…with DCE it is removed entirely :thumbsup:

it is not that simple unfortunately 😛

?

yes, the guardrails code is gone. but expound remains, which brings in cljs.pprint

-> com.fulcrologic.fulcro.application -> com.fulcrologic.guardrails.core -> expound.alpha -> expound.printer -> cljs.pprint

so with your fix my build goes to Module: :app [JS: 1.03 MB] [GZIP: 263.7 KB] while mine is at Module: :app [JS: 869.25 KB] [GZIP: 222.68 KB]

hm, why doesn’t expound get removed I wonder

I wish all this would work better ... but I can't think of a reasonable way to handle all this

in my build guardrails disappears, which means there is no ref to expound anymore

basically any library using a defmulti can't be eliminated

argh….so, I get to rewrite expound as well 😜

and fulcro while you are at it 😛

why fulcro???

unfortunately there are many things that the closure compiler doesn't understand

defmulti is one of them

spec is another

well, the side-effecting of specs is handled by guardrails…but spec itself is going to come in, yes

but part of the point of guardrails is to be able to not bloat the registry

but as far as I could tell stubbing out this namespace still works fine

https://github.com/thheller/shadow-cljs/blob/master/src/dev/com/fulcrologic/fulcro/specs.cljs

as the specs seem to be only used by the guardrails stuff

oh, I can fix that

I did the same treatment to this https://github.com/thheller/shadow-cljs/blob/master/src/dev/edn_query_language/core.cljc

there is already a >def macro that elides when gr is not enabled

since it was bringing in all the test.check stuff and generated a bunch of spec generators

that can be helped too

none of them are ever relevant to my build

yes, for sure. I was just digging through things because I wondered why my build got so big

was gonna report my findings in more detail at some point

and was thinking about possibly teaching the closure compiler about this stuff so it can remove more

cool. I’ll glance at expound…it does bother me that it is bloating the build.

when it is only a dev-time concern

did you checkout my "Inspect" stuff?

um…vague memory…remind me?

https://www.youtube.com/watch?v=9pBatlu9IWY

already looks completely different

but basically think fulcro-inspect built-in available for everything

and one thing I want to work on at some point is tracing

and maybe something spec related like the ghostwheel stuff

nice!

but with full support from the compiler

so basically I hope to support more "dev-time" stuff in a way that doesn't mess with the build too much

right now it is way to difficult to keep a build clean

Yeah, that’s nice. In the guardrails use-case I really just find using specs as a loose type system brings quite a bit of value to dev and testing.

yes absolutely

but data exporation is also a big help (thus Fulcro Inspect)…but having REBL like facilities we could hook into (auto-follow idents) would be super nice

the problem is in spec itself, just generates way too muchs tuff

REBL, fulcro-inspect and re-frame-10x are my references

REBL = neat but clojure only

fulcro, 10x = neat but CLJS only

basically I'm building this out to solve my own issues in shadow-cljs

in that I can barely ever print anything since its just too large 😛

fulcro-inspect also still copies all data I believe?

yes, that is a lot of the reason F. Inspect exists

actually, inspect does an initial copy, and then sends diffs

so, startup overhead, but light at each step

ah ok