Fork me on GitHub
#figwheel-main
<
2020-01-03
>
ingesol09:01:28

Been trying for a while now to get a smooth CLI test environment running. I’m observing that /figwheel-extra-main/auto-testing is able to auto-detect and run all my test namespaces without any extra config, while my headless CLI-runner requires me to require any test namespace I want to run. Is this a known limitation? Just curious why this is, since other test runners (kaocha, https://github.com/Olical/cljs-test-runner) have this capability as default.

mikerod18:01:03

An aspect of figwheel-main that I suppose I overlooked in the past is that I am realizing that it (1) stopped depending on cljs-build info and (2) seems like it is meant to be capable to be a cljs building tool - not just hot reloading dev workflow - actual production advanced compilation stuff as well

mikerod18:01:42

I am most surprised by (2) I guess. for the most part though, I suppose it’s just letting the cljs build config flow through to cljs compiler though

mikerod18:01:03

Curious if people are making their productionized cljs builds via figwheel-main now though?

mikerod18:01:30

when it used cljs-build I found it advantageous I could share common cljs config across profiles (was using lein). so I could have a common cljs-build, a dev one that merged the common in and used figwheel, and then a prod one that merged common stuff in but just built via cljs-build since figwheel wasn’t useful at that point

mikerod18:01:46

This could still somewhat be done, but would have to manually manage the config map common merging stuff I think (lein automatically does this type of merging)