I noticed that https://figwheel.org/docs/scripting_api.html says to start rebel readline with clj ( clj -m rebel-readline.main) rather than clojure. Is this a typo or does rebel-readline now work well with clj now?

@thiru0130 you’re right that should be clojure

clj works on my system, but I’m not going to bet that it works on every system

I’m really excited about the new stuff I’m working on right now

it will let folks run async tasks (like async tests) in a main script: clj -m figwheel.main -m exampl.test-runner

and will let them asynchronously return a value to be printed or error exit status

which will in turn allow for command line test runs that integrate well with dev ops

and other tasks

main scripts are tough to use because they will normally exit too early to allow anything useful to happen

Good stuff! I've been away for a few weeks and I'm seeing so many changes

Yup regarding clj I've had strange behaviours in the past when using it with rebel accidentally (arch linux)

I'll send a pull request with the fix to that typo.. also seeing some other copy errors with the new docs

"We’ve successfully switched between ClojureScript REPLs for our builds all the while staying in a Rebel Readline environment." <-- wohoo!

Is the "o" in this name a typo or naming convention I'm not aware of: figwheel-config-o-build

I’ve seen the -o- around

Similarly figwheel-options-o-build

yeah I’ve seen it and I kinda like it

not attached to it

I think it’s used in clojure.core

Confusing for noobs (like myself) probably.. but no big deal to get over

willing to change it

Nice thanks.. I'll include in PR

that -o- is an americanism, i think. it came from some cartoons, i suspect, when they repurposed the word automatic to different *-o-matics or something like that.

btw, for async build processes we are using https://github.com/DarthSim/overmind (or hivemind), but the biggest problem with them is how to combine them into a pipeline. many steps depend on or triggered by filesystem changes, which we monitor with http://www.entrproject.org (which is similar to http://wkf.github.io/hawk/ but without the jvm dependency), but it's cumbersome to notify another step in the build process to rerun at the right time.

what would be really good if existed is something like make, but instead of simply executing commands when a make rule is matched, it should notify an already warmed up background process...

@onetom very cool

overmind looks interesting

I’m talking more about the --main option not being able to handle any sort of async process

it will return before running async process to completion

which makes it less than optimal for js

and very useless for testing where you want something that will run the tests and system-exit with 1

on failure

@onetom also I fixed up all the cljs repl api problems that you mentioned

had to patch up piggieback a bit to get it all working

so figwheel.main/reset and friends will work properly now

wow, that's awesome. i will try it right away

its not pushed yet 🙂

😄 okay

the REPL stuff is pushed

you have to use figwheel.main 0.1.8 and piggieback 0.3.9

the async stuff isn’t there yet

i just did a quick experiment to clarify that i can't have multiple -m on the clj command-line, because subsequent -m options would be just passed as params to the first -main function.

it should work

clj -m figwheel.main -m exampl.test-runner this works for me

$ rg .
deps.edn
1:{:deps {org.clojure/clojure {:mvn/version "1.9.0"}}}

src/m2.clj
1:(ns m2)
2:(defn -main [& args] (prn "m2"))

src/m1.clj
1:(ns m1)
2:(defn -main [& args] (prn "m1, args:" args))

$ clojure -m m1 -m m2
"m1, args:" ("-m" "m2")

m1
m2

that is correct behavior

oh it prints both!!!

it shouldn’t

im just saying i haven't realized until now that some of those -m options are interpreted by the first -main function

yes that is correct

im not talking about figwheel now, just regular clojure.main in fact, that's already a bit confusing that the clj / clojure commands are running the clojure.main/-main which in turn accepts a -m/`--main` option to run another -main function in some namespace, for example figwheel.main/-main which then also interprets the next -m option to run yet another -main function...

or am i wrong about this chain somewhere?

you have that right clojure.main/-main is implicit and its’ what actually handles the CLI

and initializes the environment

it is the entry point for the java process

its kind of a turtles all the way down thing

but then i can make an uberjar, in which case my own app.main/-main (with :gen-class) will be the entry point to the java process

which i've just realized, i don't know how to make an uberjar with these new clojure cli... 😕

me either there are libs though

https://github.com/juxt/pack.alpha

the resources are not easy to find though

i've seen dnolen's Embracing Simpler Tools talk, regarding this "just make libraries" approach. very enlightening as usual! 🙂 thanks for the juxt/pack.alpha pointer!

theres another one called mahyven or something like that. its impossible to search for

@onetom There's some tools here: https://github.com/clojure/tools.deps.alpha/wiki/Tools#packaging

(Haven't tried any of them though)

At this point I want to start serving index.html from a different dev webserver than the figwheel one, such that relative AJAX calls go to the backend API dev server (written in a different language) as opposed to the figwheel dev server. As a first go, I served up an index.html from the python api dev server which pulled the css and js files from the figwheel server, and that works but subsequent js files (deps.js, cljs_deps.js, etc) fail as the browser tries to get these from python instead of figwheel. Is there an easier way to go about this?

@risinglight you need to serve the compiled static assets

from python

remember that you can configure the output-to and output-dir to place them where ever you need them to go

when you use a different server you are using a different server for everything except figwheel/repl communication which has CORS support for effortless cross origin communication

it took some finagling but that did the trick, thanks