Clojurians Log v2
ghostwheel
Any chance we can get a goog-define in stubs and normal so we can make our specs conditional on which was on the deps?
(when-not gw/stubbed?
(s/def ::thing ...)
...))
goog.DEBUG for the moment, but that doesn’t actually match up with ghostwheel (I might have ghostwheel enabled when DEBUG is false), so it can still cause problemsI guess it needs to be a cljc thing, actually….
but some way I can elide specs when I’m not using them so they don’t bloat cljs build
Alright, done – it's called >def for consistency and does exactly what we discussed, but I'm also leaving the stubbed? constant in there, because it doesn't hurt and someone might want to check that for a similar reason as with the specs here.
awesome. Thanks!
Is the work-in-progress on a published branch? Love to try it out via a git commit…oh, you’re not using deps.edn? Well, I could probably add one 😜
WIP is in a private repo, I like to clean up my history a bit before I publish, but 0.4.0-SNAPSHOT is deployed to clojars if you wanna give it a shot.
Re deps.edn – PRs are welcome. 🙂
(But wait till it's published with the uptodate dependencies and everything)
Be advised that there are some breaking changes in the config options – there's however an automatic migration in place, see ghostwheel.config/migrate-deprecated-config
And it's on by default now since we're using the stubs, so if you don't want any test code to be generated during development, set :no-check true in your ghostwheel.edn
The matching stubs version is 0.4.1
I’m dropping lein altogether…`mvn deploy` is easy to set up for clojars, and the deps features are just too valuable…works so much better than the old lein “checkouts” stuff for working on projects together from local directories. Also, deps does a much better job of resolving the dependencies.
lein is always pulling in weird versions of things that you then have to “pin”
Yeah I've been meaning to drop it for a while now, but I hadn't gotten around to looking into how to set up deps with clojars. Will ping you when the code's in the public repo so you can do the PR and then 0.4.0 will be lein-free.
All you have to do to get maven deploy to clojars going is to set up your credentials in ~/.m2/settings.xml like this:
<settings>
<servers>
<server>
<id>clojars</id>
<username>tony_kay</username>
<password>...</password>
</server>
</servers>
</settings>
I can set up the correct pom.xml for you in ghostwheel (and clj -Spom can update it anytime you change deps.edn)
then it’s just mvn deploy
Sounds useful. Right now fspecs defined with >defn or >fdef disappear in production, but of course that doesn't apply to regular data specs.
How about a simple defonce constant which is always set to true in the stubs module and set by a macro on ghostwheel load in the core module depending on whether -Dghostwheel.enabled=false?
I think that would be perfectly reliable, can't be accidentally overriden and works identically on clj and cljs.
Or even simpler, no macros, it's always on in the stubs module and always off in the regular one. You're not supposed to use the regular module in production anyway with 0.4.0, so if you disable Ghostwheel with a flag there it's fine if the specs stay and there's no need for additional complexity.
Aaaand sorted.
(...in 0.4.0)
Alternatively I could write a simple macro—`g/sdef` or something—which passes through to s/def in the core module and returns nil in the stubs.
Might be more reliable than dead code elimination.
That latter sol’n might be the best…unifies the whole story. If you have specs you need at runtime, just use s/def
ultimately my goal is keeping the cljs build small for production