figwheel-main

figwheel-main http://figwheel.org
ingesol 2020-01-03T09:26:28.012100Z

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.

2020-01-03T18:51:03.013200Z

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

2020-01-03T18:51:42.014Z

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

2020-01-03T18:52:03.014500Z

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

2020-01-03T18:52:30.015100Z

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

2020-01-03T18:52:46.015500Z

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)